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

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170313/3daa3a0f/attachment.html>

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
>>>
>>
>>

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
>>
>>
>

Thanks!

On Apr 4, 2017 1:24 PM, "Rafael Espíndola" <rafael.espindola at
gmail.com>
wrote:
> 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
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170406/ca8706bd/attachment.html>