Re: [I don't think it's off-topic at all] Linking speed for C++

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Tue, 29 May 2001 15:02:12 -0700
> From: Richard Henderson <rth@redhat.com>
> Cc: gcc@gcc.gnu.org
> Mail-Followup-To: Richard Henderson <rth@redhat.com>,
> 	Geoff Keating <geoffk@geoffk.org>, gcc@gcc.gnu.org
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> 
> On Tue, May 29, 2001 at 02:45:03PM -0700, Geoff Keating wrote:
> > On some platforms, this doesn't work the way you'd like.  Instead, the
> > PIC code is fully resolved at link time... and still generating PLT
> > entries or COPY relocs.
> 
> Hmm.  Are you sure?  It shouldn't in the case of data symbols. 
> For code symbols that is fine -- we'd be branching to the PLT
> in any case.

Consider the following example program on powerpc-linux:

#include <signal.h>
#include <stdio.h>
int main(void)
{
  printf ("%p\n", sys_siglist);
  return 0;
}

when linked normally, it has:

10010630 R_PPC_COPY        sys_siglist

When linked with -fpic, it has:

1001052c R_PPC_GLOB_DAT    sys_siglist
10010650 R_PPC_COPY        sys_siglist

(OK, _that_ is probably a linker bug.)
which comes from

        lwz 4,sys_siglist@got(30)

But when linked with -fPIC, it has:

10010650 R_PPC_COPY        sys_siglist

because the linker can't tell that the reloc, which is just

        .section        ".got2","aw"
.LCTOC1 = .+32768
.LC1 = .-.LCTOC1
        .long .LC0
.LC2 = .-.LCTOC1
        .long sys_siglist

is related to PIC-ness, or if it's just a plain old data reloc in an
oddly-named section.

> I'd class this as a linker bug if it happens.
> 
> 
> r~
> 


-- 
- Geoffrey Keating <geoffk@geoffk.org>