[llvm-dev] [lld] elf linker creates undefined empty symbol

[Rafael Avila de Espindola via llvm-dev]

Sorry, not yet. Crazy busy with internal bots.

Cheers,
Rafael

Sean Silva <chisophugis at gmail.com> writes:

> Rafael, did you ever get a chance to look at this?
>
> -- Sean Silva
>
> On Thu, Feb 23, 2017 at 1:14 AM, Sean Silva <chisophugis at gmail.com> wrote:
>
>>
>>
>> On Wed, Feb 22, 2017 at 6:14 AM, Rafael Avila de Espindola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> Sean Silva <chisophugis at gmail.com> writes:
>>> >> When __libc_start_main is hidden, it doesn't end up in the dynamic
>>> symbol
>>> >> table and so we use the default DynsymIndex of 0.
>>> >>
>>> >
>>> >
>>> > I think BFD is doing the right thing. The `extern_weak hidden` is
>>> resolved
>>> > to null since by virtue of being hidden it doesn't refer to the
>>> function in
>>> > libc.so (and there is no definition in the executable). For some reason,
>>> > LLD thinks that it needs to resolve __libc_start_main dynamically and
>>> > things go horribly wrong. Rafael, what do you think?
>>>
>>> If it is hidden it should really not end up in the dynamic symbol
>>> table. I will try to take a look at your reproducible latter in the day.
>>>
>>
>>
>> FWIW, gold issues an error:
>>
>> /usr/bin/ld.gold: error: hidden symbol '__libc_start_main' is not defined
>> locally
>> /usr/bin/ld.gold: error: hidden symbol '__libc_start_main' is not defined
>> locally
>>
>> In theory `extern_weak hidden` could still fail to have a local definition
>> and then it would resolve to 0 due to being weak, which is what BFD does.
>> But `extern_weak hidden` is still pretty questionable. E.g. in the original
>> case that Carlo ran into, this was not the expected behavior (and this
>> error may have saved him some time actually).
>>
>> -- Sean Silva
>>
>>
>>>
>>> Cheers,
>>> Rafael
>>>
>>
>>