This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: DWARF EH for PPC
- To: hjl@lucon.org
- Subject: Re: DWARF EH for PPC
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Fri, 11 Dec 1998 13:26:50 +1100
- CC: zack@rabi.columbia.edu, hjl@lucon.org, drow@cs.cmu.edu, dwarf@polaris.net, libc-hacker@cygnus.com, egcs-bugs@egcs.cygnus.com
- References: <m0znscE-00038dC@ocean.lucon.org>
> 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>