[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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.
uwe%stderr.spb.ru@localhost | Zu Grunde kommen
http://snark.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
Main Index |
Thread Index |