PIC is wasteful

[Agner Fog]

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"