llvm dev - Feb 2017 - [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>

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

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;