Patch to not create GOT and dynamic relocation entries for unresolved symbols with --warn-unresolved-symbols.

[H.J. Lu]

On Fri, Apr 10, 2015 at 7:18 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>> However, with -fPIE
>>
>> $ g++ -O2 -fPIE foo.cc -pie
>> foo.cc:function main: warning: undefined reference to 'foo()'
>>
>> but
>> $./a.out
>> ./a.out: symbol lookup error: ./a.out: undefined symbol: _Z3foov
>>
>> because with fPIE, a function pointer access is using a GOTPCREL
>> relocation which creates a GOT entry and a dynamic relocation for it.
>> The dynamic linker does not like the unresolved symbol any more.
>>
>> I have attached a patch to prevent creation of GOT and dynamic
>> relocation entries with --warn-unresolved-symbols in general.  Is this
>> reasonable?
>
> No, I don't think so. For static links, we statically resolve
> undefined symbols to zero, but for non-static links, we leave them for
> dynamic resolution, presuming that they might be resolvable at
> runtime. This patch would change linker behavior that is fairly well
> established. (This patch also changes only x86_64 behavior; you'd need
> a similar patch for all targets. For a problem that isn't really
> target-specific, I'd prefer a target-independent solution.)
>
> The difference between non-PIE and PIE here is not due to the linker's
> -pie option, but because the compilers -fPIE option caused the
> compiler to use the GOTPCREL relocation, which requires the linker to
> create a GOT entry.
>
> If the reference to foo is weak, the dynamic loader won't complain --
> I think that's really what you want. I'm not sure whether it's
> reasonable for you to have the compiler make these symbols weak unsats
> or not, but if you can, you wouldn't need --warn-unresolved-symbols
> any longer. If not, I wouldn't object to a new
> --weak-unresolved-symbols option that would have the linker convert
> any unresolved symbols (that it warned about) into weak references. I
> don't think we want to do that by default, since it changes existing
> expectations, but I think it's fine as an option.
>
> HJ, does that sound like a reasonable option for Gnu ld as well?
>

This sounds reasonable to me.

-- 
H.J.