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

[Rafael Espíndola via llvm-dev]

OK, I finally had time to take a look. The issue was just us not
realizing that a hidden undef and a definition in a .so should not be
treated like the same symbol.

Fixed in r299464.

Cheers,
Rafael

On 13 March 2017 at 22:04, Sean Silva <chisophugis at gmail.com> wrote:
> 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
>>
>>
>