Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Tue, 11 Jul 2000 12:48:32 -0700 (PDT)
> From: Linus Torvalds <torvalds@transmeta.com>
> cc: gcc@gcc.gnu.org
> 
> 
> 
> On Tue, 11 Jul 2000, Geoff Keating wrote:
> > > 
> > > Is there something really wrong with just sidestepping this issue
> > > altogether with the following simple rule:
> > > 
> > >  - libgcc is always statically linked inside the object file that needs
> > >    it (be it a binary or a shared library)
> > > 
> > > Yes. It will result in code duplication. Is that a huge problem?
> > 
> > Yes.  There is at least one routine in libgcc that must not be
> > duplicated; it relies on there being only one copy of itself in the
> > whole program.  This is the routine causing all the trouble.  We also
> > occasionally want to modify this routine, and you can't do that if
> > it's linked statically into every program.
> 
> Ok. It sounds like that is a special routine, though. Mind if I ask why?

This is the routine that keeps track of all the exception-handling
information.  Consider a program that uses the standard C function
qsort, but the comparison function can detect an I/O error (it's
sorting pointers to on-disk data) and throw an exception back to the
application.  The exception throwing mechanism has to know how to
unwind the comparison function's stack frame and the qsort stack
frames and then find the handler in the application which can
deal with the error; in general, it needs to know about every bit of
code loaded into the process.

> Might it not be better to consider that routine part of the crt0 kind of
> startup logic instead of a libgcc?

You mean, the crt1.o which is nine instructions long on powerpc, or
the startup logic which is ~1k lines in glibc?  We don't want the
first as it makes it impossible to upgrade as crt1 is linked into
every application, and the second is the current situation.

...
> Right now gcc cannot change the interfaces to the simple libgcc routines,
> because gcc doesn't control what libgcc things get linked against. Which
> means, for example, that optimizing things like "_cmpsdi2" to use a
> non-standard (and saner) calling convention etc is just not possible
> without strange and wonderful versioning schemes.

It's not that hard.  You simply call your new routine a new name.

-- 
- Geoffrey Keating <geoffk@cygnus.com>