This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


I have attached a patch to add  --weak-unresolved-symbols to gold.

Please let me know what you think.

Thanks
Sri


On Sat, Apr 11, 2015 at 6:28 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.

Attachment: weak_unresolved_symbols_patch.txt
Description: Text document


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