This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- To: Linus Torvalds <torvalds at transmeta dot com>
- Subject: Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 11 Jul 2000 18:25:28 -0300
- Cc: Geoff Keating <geoffk at cygnus dot com>, gcc at gcc dot gnu dot org
- Organization: GCC Team, Red Hat
- References: <Pine.LNX.4.10.10007111242490.7242-100000@penguin.transmeta.com>
On Jul 11, 2000, Linus Torvalds <torvalds@transmeta.com> wrote:
> Ok. It sounds like that is a special routine, though. Mind if I ask why?
IIUC, the actual problem is that there are some static variable(s?)
used to store frame data, so, if there are multiple copies of such
variables (which occurs when each shared library provides its own),
programs break.
> Might it not be better to consider that routine part of the crt0 kind of
> startup logic instead of a libgcc?
This might very well work, as long as it doesn't make it to shared
libraries. However, it would require users of shared libraries
created with GCC to link with this crt file too.
The solution people have been proposing, of moving libgcc into a
separate shared library, would fix the problem for GNU/Linux, because
then each library wouldn't have its own copy of the EH-region-registry
functions nor of this variable. However, it wouldn't solve the
problem on systems that don't store library dependencies in shared
libraries. In such systems, shared libraries created with gcc would
have to be linked with libgcc in order to get the EH-region-registry
functions. I'm pretty sure there are people out there that won't like
this, particularly people creating dlopen-able modules that are
intended to be dlopened by programs not linked with GCC.
Another idea that occurs to me: couldn't we just make this variable
non-static, so that dynamic loaders would resolve all references to it
into a single memory region?
Of course, this creates room for abuse of the interface (people might
feel tempted to use this variable directly), but we could document
this in the variable name, and give the users the choice of burning
themselves.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me