Re: libgcc

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Tue, Dec 08, 2009 at 06:33:31 +0000, Nick Hudson wrote:

> On Tuesday 08 December 2009 02:17:19 you wrote:
> > > Would not be an issue if libc had a dependency recorded against the
> > > shared libgcc, yes?
> >
> > I think so.
> >
> > And now I'm trying to understand the condition how libgcc is linked. 
> > bsd.lib.mk makes libc.* get linked against libgcc_pic.a.  I can't
> > understand the point;
> 
> IIRC (and I'm not sure I do) libgcc_pic.a is linked against libc in
> the same way as all other libraries to provide things like $$dyncall
> on hppa which isn't available anywhere else and needs to be included
> in the libc. It's also there just in case there are other similar
> functions on other architectures.

On sh3 (and on hppa, iirc) libgcc_pic.a contains "millicode" -
functions like __sdivsi3 that don't really follow normal function call
convnetions w.r.t. register usage.  That means every shlib must have
its own .hidden copy (supplied by libgcc_pic.a), otherwise calls to
millicode lose, b/c when they go through rtld, registers got clobbered
(as part of normal function call convnetion) that are not supposed to
be clobbered during millicode call.

> > what if libc.* has no undefined symbols that live in libgcc_pic.a?
> 
> This is the common case and it means that nothing from libgcc_pic.a
> get pulled into libc.
>
> > I wonder if what it really meant was LDADD+=--whole-archive
> > -lgcc_pic.a...

No, you don't want to pull all the millicode, only the one that is
actually needed by the shared library.

SY, Uwe
-- 
uwe%stderr.spb.ru@localhost                       |       Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/          |       Ist zu Grunde gehen