This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

__frame_state_for has dissappeared from libgcc

The new exception handling code no longer defines __frame_state_for.
Consequently, this symbol has disaapeared from libgcc.  One can raise
similar objections to this as with __eprintf.  However contrary to the
__eprintf-case, I expect that the removeal of __frame_state_for from
the shared libgcc will cause serious problems, at least on GNU systems
(the Hurd, Linux):

 * Rebuilding glibc with the current GCC (both branch and mainline
   now) will probably break exception handling for existing binaries,
   and new binaries created using existing shared libraries.  Glibc
   includes a limited set of exception handling code to make exception
   handling work reliably for shared libraries (see
   config/libgcc-glibc.ver in the GCC tree).  This includes
   __frame_state_for.  Rebuilding with glibc with the current GCC will
   result in a shared libc that no longer exports __frame_state_for.
   I shouldn't need to explain that removal of any symbol from a
   shared library implies breaking backwards compatibility.

 * Deferring the implementation of the exception handling functions in
   glibc to libgcc via DT_AUXILIARY will lead to similar problems.
   The registration functions from libgcc will be used, but binaries
   using the old exception handling stuff will call __frame_state_for
   in glibc.  Since the EH info isn't availible within glibc this will

I don't know whether it is possible to re-implement __frame_state_for
on top of the new exception handling code.  If it is possible, such an
implementation should be added to unwind-dw2-fde.c.  It might be
necessary to reorginize things such that the references to
__register_frame* and __deregister_frame* in glibc won't suck in too
much object modules from libgcc.a.

If it is not possible to re-implement __frame_state_for on top of the
new exception handling code, some serious thought is needed ...

Anyway, I also think that it is of the utmost importance that the
glibc and GCC people work out how the new exception handling code is
integrated into glibc, and whether DT_AUXILIARY will indeed be used in
glibc.  Ulrich has left this issue alone for quite some time now.
If we do nothing, the very least that will happen is that exception
handling in dlopen'ed modules won't work.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]