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

[Jason R Thorpe]

On Fri, Jul 14, 2000 at 05:46:22PM +0100, Richard Earnshaw wrote:

 > Yes.  They are still there.  And because of the way shared libs work I 
 > believe they have to be.  Consider something like __divsi3 and then assume 
 > that it isn't in libc.so and that we don't have a shared libgcc.  There 
 > are two ways the linker could work:
 > 
 > 1) The linker doesn't resolve symbols from shared libs into archives: If 
 > it is needed by libc.so and it weren't needed by the application the 
 > linker wouldn't put it into the application.  So we would get a run-time 
 > fault when the symbol isn't found.
 > 
 > 2) The linker does resolve symbols from shared libs into archives: this 
 > would result in every symbol possibly needed by libc from libgcc getting 
 > put into the static part of the application even if it weren't needed for 
 > that application (the linker can't pick apart the dependencies of the 
 > shared lib).  This leads to code bloat since now we include __divsi3 in 
 > our app even if we never call it.

Err... ok, now I think I'm confused.

Looking at NetBSD shared library build rules, we basically see what
amounts to:

	ld -x -shared -soname libc.so.12 -o libc.so.12.62 \
	    /usr/lib/crtbeginS.o \
	    --whole-archive libc_pic.a --no-while-archive \
	    /usr/lib/crtendS.o

Hm, are you referring to just the quad support library?  Otherwise,
what kinds of compiler support routines would libgcc be providing on
e.g. the Alpha?

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>