Re: __register_frame_info problem on Alpha

[Geoff Keating <geoffk@ozemail.com.au>]

> Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm
> Date: Wed, 26 May 1999 20:14:56 +0200
> From: Thorsten Kukuk <kukuk@suse.de>
> Cc: egcs@egcs.cygnus.com, libc-hacker@sourceware.cygnus.com
> 
> On Wed, May 26, Ulrich Drepper wrote:
> 
> > Thorsten Kukuk <kukuk@suse.de> writes:
> > 
> > > I would like to not see this symbol in libc.so.6.1. Or we will have
> > > again this problems, because current Alpha distributions doesn't have
> > > this symbol, and our SuSE Linux AXP Beta also. So the first 
> > > distribution after a new egcs/gcc version will have this symbols, 
> > > and we have the problems again.
> > 
> > We cannot have this function simply missing.  It is actively used.
> > And since libgcc is no shared object it is picked up and put in the
> > shared lib.
> > 
> > If the compiler has such a big change there is no backward
> > compatibility guaranteed.  Simply let the people use the right
> > versions.  If somebody updates a compiler independent from the rest of
> > the distribution s/he must be prepared to do some more work (e.g.,
> > installing a new libc which you can provide).
> 
> It is not the problem what the people do. It is a very big problem
> for distributors. All Distributors have a glibc on Alpha without
> __register_frame_info. Nobody could do the switch and use a new
> compiler. The first who do this becomes big problems with software
> vendors, because they couldn't use this distribution as development
> platform for all Linux distributions. 
> 
> Yesterday I got an email, if it is really necessary to make
> three versions of his product: libc5, glibc2.0 and glibc2.1.
> Should he now make 4 ? one with register_frame_info, one without ?

The short answer is that he probably only needs to make at most two: a
libc5 one and a glibc 2.0 one with register_frame_info (unless he
wants to use glibc 2.1 features like LFS support, of course).

I propose the following glibc FAQ entry:

Q: When I run a program, it complains that __register_frame_info is
undefined.  What's wrong?

A: There are two systems gcc can use to handle exceptions.  One is
based on using setjmp() at every place where an exception can be
caught, and longjmp() everywhere an exception can be handled or a
destructor may need to be called.  This system requires no special
treatment from glibc, since glibc doesn't throw or catch exceptions
itself.  This is the older exception system.

The newer system is more complex.  It calls __register_frame_info once
for each shared object loaded into the program for which exceptions
can be thrown _through_.  __register_frame_info puts all this
information into a single, global table.  Then when an exception is
thrown, this information is examined to determine where it is caught
and what needs to be done to get there.

The tricky part is that glibc does have routines which exceptions
can be thrown through; an example is qsort().  So it needs to have
__register_frame_info available to it.  Since executables compiled
under the older system won't have this routine, it must be in
glibc.  Since there must be only one copy of this routine (because
there must be a single, global table) it must also be exported from
glibc, so that it can be seen by applications.

However, this _does not_ mean that applications should use the version
defined in glibc.  They should always provide their own version, just
as with all the other routines gcc defines (found in libgcc.a), and
have glibc use that one.  This can be achieved by linking libgcc.a
before libc, like `ld -o foo foo1.o foo2.o -lgcc -lc'.  Normally, you
would use gcc or g++ to link and it should do this automatically if you
just say 'gcc -o foo foo1.o foo2.o'.

If you do this, your application will always have its own
__register_frame_info routine and everything will be OK.  It will work
whether or not glibc has __register_frame_info. If you are using glibc
2.1 or later and it has been compiled with the newer exception
handling you will even be able to throw exceptions from qsort()
comparison routines.

If you're not using any variant of gcc as your compiler, you can just
forget about all this.  You won't (presumably) need any of the
routines in libgcc.a, so you can just link with -lc.

Finally, if you're linking statically, you need to do the reverse:
link with libgcc.a after libc.a, because libc.a might need something
in libgcc.a.  It won't hurt to just always do both by linking like
`ld -o foo foo1.o foo2.o -lgcc -lc -lgcc'.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>