Re: Problems with exception handling in glibc and gcc.

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Tue, 4 Jul 2000 14:02:32 +0200 (MET DST)
> From: Mark Kettenis <kettenis@wins.uva.nl>

>    If we don't export the functions from glibc, how do applications gain
>    access to glibc's EH frame information?  There are a number of glibc
>    functions that are supposed to support throwing exceptions (from user
>    procedures passed to them), like qsort and tsearch.
> 
> By doing the same trick as GCC's crtstuff.c does (IIRC since egcs
> 1.0.3).  Have a weak reference to __register_frame_info, and call it
> if its non-NULL (i.e. if the program picked up a copy of those
> functions because it actually *uses* the EH frame info).

Actually, if there is a weak reference to __register_frame_info, the
linker will look for it in libgcc.a and it will only be NULL if there
is no copy there (which would only happen if the program was not
linked with GCC).  That's why this is so tricky, because it affects
many C programs and libc.  If it only affected C++, we could just
break the ABI again and probably no-one would notice.

>    This is not a sudden new restriction.  As HJ mentioned, it has been
>    around since at least 1997.  In fact, I proposed that we put a comment
>    in frame.h one of the last times this happened, I think in late 1999.
>    "Those who do not remember history..."
> 
> Indeed.  And over the past few years, we've been applying stopgap
> after stopgap to solve these problems.  We should stop doing that
> right now, and plan ahead instead.  This requires some cooperation

This is an incredibly good idea.

> between GCC and the glibc project.  IMHO both glibc 2.2 and GCC 3.0
> should not be released before we have a proper solution that has been
> verified to work.  This might very well include turning parts of
> libgcc into a shared library.

I think it's probably too late for glibc 2.2, but we could easily make
this change in a 2.2.* version.

...
> Blindly turning libgcc into a shared library wouldn't be very wise.  I
> share Geoff's worries about it, especially if libc.so is somehow tied
> to libgcc.so.

Of course, libc.so will use libgcc.so.  This isn't really any
different to any other shared library (all of them will no doubt use
libgcc.so, since they're all built with GCC).

...
> But it might be possible to prevent new programs from linking against
> the versions in glibc, such that they won't ever use the copies in
> glibc again.  However, doing so only makes sense if GCC and the rest
> of the toolchain make sure that a single copy of the frame info
> functions is used.

It's easy to prevent new applications (well, those that are compiled
against new versions of glibc, which is not the same thing since
people often want their applications to run with old versions of glibc
too and often want to use the latest compiler to build them) from
doing this.

It's not clear what this would gain at present, though.  We certainly
don't want to embed copies of __register_frame_info in every
application, because at least now we can change the copy in glibc by
requiring people to upgrade; we can't ask everyone to relink their
applications.  

If we had done that six months ago we would now be completely stuck
because we couldn't add the new DWARF opcode; and I understand that
it's quite likely we will implement more DWARF opcodes in future.

-- 
- Geoffrey Keating <geoffk@cygnus.com>