Re: PIC is wasteful

[Agner Fog <agner at agner dot org>]

On 23-06-2011 15:53, Andrew Haley wrote:
> On 06/23/2011 02:35 PM, Agner Fog wrote:
> > Question 3:
> > ----------------
> > When I make a self-relative reference to a public variable in a 64-bit
> > .so I get the linker error:
> > relocation R_X86_64_PC32 against `VariableName' can not be used when
> > making a shared object; recompile with -fPIC
> > This message is illogical because the reference is indeed
> > position-independent. It appears only when the variable is public, not
> > when it is local.
> Think about what happens if the executable defines that same symbol.
> If that happens, all references to that symbol must refer to the
> same location in the executable.
Thank you for the explanation. That makes sense. But I would expect the 
linker to make an error message if two symbols have the same name. Why 
does a GOT entry solve the problem - you still have two symbols with the 
same name? The GOT should be transparent to the C/C++ programmer.
> > Apparently, gcc avoids the problem by using a GOT
> > entry when the variable is public. I can solve the problem in assembly
> > by giving the variable two names, one public and one local, and making a
> > relative reference to the local name.
> > Why does gcc not use the same trick?
> Because it's broken: there can only be one instance of a symbol X in
> a running program, and every reference to X must refer to the same
> memory.
It's not broken. Just apply two names to the same memory location (gas 
syntax):
.globl name1
name1:
name2:
.string    "This text string has two names"