This is the mail archive of the mailing list for the GCC project.

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

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

> Date: Tue, 29 May 2001 15:02:12 -0700
> From: Richard Henderson <>
> Cc:
> Mail-Followup-To: Richard Henderson <>,
> 	Geoff Keating <>,
> 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 <>

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