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

[Linus Torvalds <torvalds at transmeta dot com>]

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?
Might it not be better to consider that routine part of the crt0 kind of
startup logic instead of a libgcc?

The downside with the current dynamic libgcc extends past the silly
trouble with interfacing to libc. I wouldn't think that it is unreasonable
to change libgcc semantics in between compiler versions, yet I don't think
it should be impossible to link dynamic libraries compiled with one
compiler against a binary compiled with another.

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.

			Linus