This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
A completely different approach to EH runtime
- To: gcc at gcc dot gnu dot org
- Subject: A completely different approach to EH runtime
- From: "Zack Weinberg" <zackw at stanford dot edu>
- Date: Tue, 20 Feb 2001 22:04:05 -0800
I thought of this in the shower this morning. It is a completely
different way of getting exactly one copy of the EH runtime into code
that needs it. It probably won't work, but I thought I'd throw it out
there for reactions.
Put all the language-independent EH support in their own library, call
it libeh.a. This is a static library. __muldi3 etc continue to live
in libgcc.a. Shared objects are linked with libgcc.a but _not_
libeh.a.
Create a crteh.o whose sole purpose is to drag the EH support routines
into an executable which does not necessarily reference them itself,
but may be linked with shared libraries, or load dynamic objects, that
do. It can also take over calling __register_frame_info for the
executable from however that's done now.
All executables linked with -fexceptions (whether or not that's the
language default) get crteh.o thrown in right after crtbegin.o, and
libeh.a at the very beginning of the library list. Therefore all the
libraries bind to the copy of the eh routines in the executable.
Should we ever add a new EH ABI, we will need to retain the old
interface (hopefully just a wrapper around the new one) and force it
to be present even in executables that don't use it, in case shared
libraries need it.
This should just work on every platform which does not use GNU libc.
On platforms which do, there is an additional complication: glibc
presently contains its own copy of the eh routines, dragged in from
libgcc.a. For this scheme to work, those copies have to be made
invisible at link time, and the executable's copies have to be used at
load time if present, but if they aren't, then libc's copies have to
be used. I don't know if this is feasible.
Why does glibc contain the eh routines? It was the best solution
available at the time (late '98, IIRC) to the__register_frame and
__register_frame_info fiasco. Go look up the flame wars on gcc,
gcc-patches, and libc-hacker. There were about five of them.
zw