GNU libc and gcc exception handling

[Mark Kettenis <kettenis@phys.uva.nl>]

We should stop contaminating the libc ABI with compiler specific
symbols.  Therefore we should stop submitting patches without proper
explanation and try to make a proper analysis of the problems first.

The reason why references to the exception handling functions end up
in all programs and shared libraries produced by gcc (2.8.1 or egcs),
is that they are referenced by `crtbegin.o' and `crtbeginS.o'.  I
don't know why, but I guess it is because the linker cannot guess if
any of the modules it is handling use exception handling.

There are only two functions that are used by `crtbegin.o' and
`crtbeginS.o': `__register_frame_info' and `__deregister_frame_info'.
It is desirable to include them in the shared libc, because otherwise
they would end up in all other properly linked shared libraries.

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 are also `__register_frame' and `__deregister_frame' (and
`__register_frame_table').  These are backwards compatibility
functions for use with code compiled with previous versions of gcc (I
believe for gcc 2.7, where IIRC exception handling was still
experimental, and maybe early versions of egcs).  I don't think
they have to be exported from the shared libc since nobody should have
distributed binaries that used them, and the binaries probably do not
contain any undefined references to them.  If they are referenced by
shared libraries, linking to these libraries will resolve these
symbols from libgcc.a.

Mark