Sean Silva via llvm-dev
2017-Feb-22 07:34 UTC
[llvm-dev] [lld] elf linker creates undefined empty symbol
On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Carlo Kok <ck at remobjects.com> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > >> > >> If you pass --reproduce foo.tar to lld it will create a foo.tar file > >> with all that is needed to reproduce the link. > >> > >> Can you also share how you created the various .o files? If so I might > >> be able to try reducing the issue. > > > > It's created by my own compiler. > > > > https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0 > > > > My biggest problem is that I have no idea where I can start trying to > > narrow it down, on the so side, or on the executable side, the error is > > rather strange to begin with. > > I would suggest setting up a script that links each .so and executable > with either lld or bfd. That way you should be able to find which link > causes the problem. > > After that start reducing the problem. If it was c++, you would run > delta on the .ii file checking that the bfd linked program/library works > and that the lld linked one fails to load. >Carlo seems to be passing --lto-O0 so bugpoint might be a viable alternative as well if the input is bitcode. -- Sean Silva> > Cheers, > Rafael > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170221/b9c87ac0/attachment.html>
Carlo Kok via llvm-dev
2017-Feb-22 11:12 UTC
[llvm-dev] [lld] elf linker creates undefined empty symbol
On 2017-02-22 08:34, Sean Silva wrote:> > > On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Carlo Kok <ck at remobjects.com <mailto:ck at remobjects.com>> writes: > > > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: > >>> Input files: > >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 > <https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0> > >> > >> If you pass --reproduce foo.tar to lld it will create a foo.tar file > >> with all that is needed to reproduce the link. > >> > >> Can you also share how you created the various .o files? If so I might > >> be able to try reducing the issue. > > > > It's created by my own compiler. > > > > https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0 > <https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0> > > > > My biggest problem is that I have no idea where I can start trying to > > narrow it down, on the so side, or on the executable side, the error is > > rather strange to begin with. > > I would suggest setting up a script that links each .so and executable > with either lld or bfd. That way you should be able to find which link > causes the problem. > > After that start reducing the problem. If it was c++, you would run > delta on the .ii file checking that the bfd linked program/library works > and that the lld linked one fails to load. > > > Carlo seems to be passing --lto-O0 so bugpoint might be a viable > alternative as well if the input is bitcode. > > -- Sean SilvaShould anyone ever get this, Sean Silva found this: declare extern_weak hidden void @__libc_start_main(i32 (i32, i8**, i8**)*, i32, i16**, i32 (i32, i8**, i8**)*, void ()*) triggered a rogue relocation to (0). Making it non hidden fixes this. Rafael, weird thing is, gnu ld is perfectly fine with this, so not sure if this is a bug.>-- Carlo Kok RemObjects Software
Sean Silva via llvm-dev
2017-Feb-22 11:47 UTC
[llvm-dev] [lld] elf linker creates undefined empty symbol
Rafael, here is a repro.tar to look at: https://reviews.llvm.org/F3100177 The attached foo.diff adds a print which shows the issue. ``` NAME: sleep SYMINDEX: 2 NAME: sched_yield SYMINDEX: 1 NAME: __libc_start_main SYMINDEX: 0 ``` `readelf --relocs` Shows that we create : ... 000000255110 002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat at GLIBC_2.2.5 + 0 000000255118 001e00000007 R_X86_64_JUMP_SLO 0000000000254420 __fxstat at GLIBC_2.2.5 + 0 000000255120 000000000007 R_X86_64_JUMP_SLO 0 000000255128 002c00000007 R_X86_64_JUMP_SLO 0000000000254440 uname at GLIBC_2.2.5 + 0 000000255130 001b00000007 R_X86_64_JUMP_SLO 0000000000254450 getenv at GLIBC_2.2.5 + 0 ... 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. -- Sean Silva On Wed, Feb 22, 2017 at 3:12 AM, Carlo Kok <ck at remobjects.com> wrote:> > > On 2017-02-22 08:34, Sean Silva wrote: > >> >> >> On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Carlo Kok <ck at remobjects.com <mailto:ck at remobjects.com>> writes: >> >> > On 2017-02-21 20:33, Rafael Avila de Espindola wrote: >> >>> Input files: >> >>> https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0 >> <https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0> >> >> >> >> If you pass --reproduce foo.tar to lld it will create a foo.tar >> file >> >> with all that is needed to reproduce the link. >> >> >> >> Can you also share how you created the various .o files? If so I >> might >> >> be able to try reducing the issue. >> > >> > It's created by my own compiler. >> > >> > https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0 >> <https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0> >> > >> > My biggest problem is that I have no idea where I can start trying >> to >> > narrow it down, on the so side, or on the executable side, the >> error is >> > rather strange to begin with. >> >> I would suggest setting up a script that links each .so and executable >> with either lld or bfd. That way you should be able to find which link >> causes the problem. >> >> After that start reducing the problem. If it was c++, you would run >> delta on the .ii file checking that the bfd linked program/library >> works >> and that the lld linked one fails to load. >> >> >> Carlo seems to be passing --lto-O0 so bugpoint might be a viable >> alternative as well if the input is bitcode. >> >> -- Sean Silva >> > > > Should anyone ever get this, Sean Silva found this: > > declare extern_weak hidden void @__libc_start_main(i32 (i32, i8**, i8**)*, > i32, i16**, i32 (i32, i8**, i8**)*, void ()*) > > triggered a rogue relocation to (0). Making it non hidden fixes this. > > Rafael, weird thing is, gnu ld is perfectly fine with this, so not sure if > this is a bug. > > > >> > -- > Carlo Kok > RemObjects Software >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170222/6462969a/attachment.html> -------------- next part -------------- diff --git a/ELF/SyntheticSections.cpp b/ELF/SyntheticSections.cpp index 19326bc..05fb9e3 100644 --- a/ELF/SyntheticSections.cpp +++ b/ELF/SyntheticSections.cpp @@ -1031,6 +1031,7 @@ template <class ELFT> void RelocationSection<ELFT>::writeTo(uint8_t *Buf) { // in account 'local' and 'global' GOT entries. P->r_offset += In<ELFT>::MipsGot->getTlsOffset(); P->setSymbolAndType(Rel.getSymIndex(), Rel.Type, Config->Mips64EL); + errs() << "NAME: " << Rel.Sym->getName() << " SYMINDEX: " << Rel.getSymIndex() << "\n"; } if (Sort) { diff --git a/ELF/SyntheticSections.h b/ELF/SyntheticSections.h index a1190d2..9f99931 100644 --- a/ELF/SyntheticSections.h +++ b/ELF/SyntheticSections.h @@ -290,8 +290,8 @@ public: uint32_t Type; -private: SymbolBody *Sym; +private: const InputSectionBase<ELFT> *InputSec = nullptr; uintX_t OffsetInSec; bool UseSymVA;