Re: PATCH: Share the dwarf2 unwind code between glibc and gcc 3.0

[Jakub Jelinek <jakub at redhat dot com>]

On Mon, Jul 09, 2001 at 01:03:58PM +0100, Jason Merrill wrote:
> >>>>> "Mark" == Mark Kettenis <kettenis@science.uva.nl> writes:
> 
> > Jason Merrill <jason_merrill@redhat.com> writes:
> >> I thought this was why we created libgcc_s.so--so that we wouldn't have to
> >> worry about keeping the copy of libgcc in glibc up to date.  Why can't
> >> glibc just link against the shared libgcc?
> 
> > __frame_state_for is part of the libc.so ABI, and is no longer part of
> > libgcc_s.so (and libgcc.a).  We either have to roll our own version
> > for glibc, or it has to be reimplemented in GCC and added back to
> > libgcc.
> 
> I think it makes sense to provide it in glibc for backwards compatibility.
> But it should be a wrapper around the new libgcc APIs if possible.

As Mark pointed out, uw_frame_state_for won't give you eh_ptr, so
__frame_state_for cannot be built just by calling uw_frame_state_for in
libgcc_s.so.1 and then doing some conversion.
On the other side, __frame_state_for implementation in GLIBC does not have
to support all extensions which are added in the latest GCC found on a
system; it needs to support whatever extensions are needed for
a) unwinding of the few GLIBC routines built with -fexceptions, created by
   GCC which compiled GLIBC (which does not need necessarily be the latest
   experimental compiler on the system)
b) unwinding potentially other C routines which were compiled with
   -fexceptions in shared libraries which need to maintain binary
   compatibility (if there are any, there are very few such libraries)

> > Apart from that, plain linking libc.so against libgcc_s.so would
> > effectively make the libgcc_s.so ABI part of the libc.so ABI.  That might
> > be undesirable.  Then it might not...  I don't have a really strong
> > opinion about that.
> 
> It seems to me that including the functions in glibc itself does the same
> thing, only worse.  If glibc uses the libgcc interface rather than
> copying it, libgcc can be updated for new gcc releases without requiring
> a new glibc release as well.

GLIBC would export:
- the registration/deregistration functions plus _Unwind_Find_FDE
- on platforms which need it __frame_state_for too.
The point here was not to punish programs which don't use exception
handling at all (I think this is still the majority of programs
on average Linux box) and support pre-G++ 3.0 binaries.
The punishing would include:
- additional overhead at run-time for mmapping libgcc_s.so, resolving of its
  symbols
- higher memory footprint (both in the number of shareable and non-shareable
  pages)
3.0+ compiled programs/libraries which need exceptions would still use
exceptions from libgcc_s.so.1 (except that in the rare case where glibc
would come earlier in the search path than libgcc_s, then the
registration/_Unwind_Find_FDE stuff would be used from glibc).

	Jakub