This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: DWARF EH for PPC


> From: hjl@lucon.org (H.J. Lu)
> Date: Wed, 9 Dec 1998 15:01:54 -0800 (PST)
> Cc: zack@rabi.columbia.edu, hjl@lucon.org, drow@cs.cmu.edu, dwarf@polaris.net,
>         libc-hacker@cygnus.com, egcs-bugs@egcs.cygnus.com
> 
> > 
> > 
> > I might add that this sort of problem is not just related to glibc,
> > egcs or C++.
> > 
> > For instance, on my machine there is a library routine in libgcc.a
> > "__divdi3", which (I think) performs division of 'long long's.  The
> > shared library "libext2.so.2" currently uses it, and so (because like
> > all shared libraries it is linked with libgcc.a) it defines it:
> > 
> > 0001038c g    DF .text  000005b4  Base        __divdi3
> > 
> > But this means that any application program linked with this library
> > will _not_ include this routine, because it is in the shared library
> > which is linked before libgcc.a.  Now, suppose the library is changed
> > so that it no longer requires this routine.  Then all those
> > applications would break.
> 
> It won't happen. That is one reason we keep those old __register_frame
> functions in frame.c even though egcs doesn't use them anymore. With
> shared library, you may not remove any functions from libgcc.a and 
> you cannot change their ABIs. It is trivial to make sure __divdi3 will
> be in libfoo.so on Linux. Just add
> 
> 	extern void __divdi3 ();
> 	__divdi3 ();
> 
> to crtstuff.c around line 375. You will see those codes are never
> reached. But it ensures those symbols will be included in libfoo.so.

But you have to do this for _every_ routine in libgcc.a!  You might
just as well use

ld ... foo.o -lc --whole-archive libgcc.a --no-whole-archive

to link everything.

Any libgcc.a routine may end up in a shared object, and any shared
object might be changed so that its external interface doesn't change
but the set of libgcc.a routines that it uses changes.

> > Alternatively, I think Zack proposed a solution where libgcc.a was
> > linked to every object before any shared objects.  This would work,
> > because it would ensure that any executable that needed it had a copy
> > of (say) __divdi3 of its own.  I recommend this solution.
> > 
> 
> I haven't studied it in details. I don't know if you can cover all
> permutations allowed by gcc, like:
> 
> # gcc .... foo.o -lbar bar.o

You may need more than one -lgcc:

ld ... foo.o -lgcc -lbar bar.o -lgcc -lc -lgcc

This is no problem.  If you didn't want to be clever about it, just
add a -lgcc before every object:

ld ... -lgcc foo.o -lgcc -lbar -lgcc bar.o -lgcc -lc -lgcc

It'll probably slow the linker a bit to do it this way, but it's easy
to optimise this approach for the case of many object files:

ld a.o b.o c.o d.o -lgcc -lbar -lgcc bar.o foo.a -lgcc -lc -lgcc

and that'll cover most of the obvious cases.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]