Re: GNU libc and gcc exception handling

[Andreas Schwab <schwab@issan.informatik.uni-dortmund.de>]

Mark Kettenis <kettenis@phys.uva.nl> writes:

|> All other functions (with the exception of the compatibility functions
|> discussed below) are only needed by modules that actually use the
|> exception handling functionality.  For now, that means only C++
|> programs and shared libraries.  Therefore I don't think that they
|> belong in libc.  If we don't export them they will end up in the
|> shared libstdc++ or will be picked up from libgcc.a if one produces a
|> program or shared library that contains C++ code but doesn't link to
|> libstdc++.

There is a fundamental problem with the exception support in libgcc.a: it
uses static data (in libgcc.a:frame.o) that must be unique in the whole
program.  All other modules of libgcc.a are completely self-contained, and
can tolerate multiple active occurences of itself in the same binary
(i.e., the executable and all dynamically linked objects together).

But frame.o must be kept unique.  Moreover, libc.so itself contains frame
unwind information, and it must register them with the one and only active
instance of frame.o, otherwise it is impossible to unwind the stack
through callback functions passed to qsort, hsearch, etc. (those functions
are explicitly compiled with exception support in libc).  Thus it is not
possible to remove the references to __register_frame_info from libc, and
we must make sure to export the functions, even if libc is linked against
libgcc.a:frame.o, so that all other shared libraries use the active
instance of it.  The other libraries can still contain copies of the code
from libgcc.a on its own, but __register_frame_info and
__deregister_frame_info must always be global functions, so that all calls
resolve to the same instance.

Andreas.