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

[Sean Silva via llvm-dev]

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>