Rafael Avila de Espindola via llvm-dev
2017-Feb-22 14:14 UTC
[llvm-dev] [lld] elf linker creates undefined empty symbol
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. Cheers, Rafael
Sean Silva via llvm-dev
2017-Feb-23 09:14 UTC
[llvm-dev] [lld] elf linker creates undefined empty symbol
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/20170223/fadff065/attachment.html>
Sean Silva via llvm-dev
2017-Mar-14 02:04 UTC
[llvm-dev] [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>