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

[Sean Silva via llvm-dev]

On Wed, Feb 22, 2017 at 3:47 AM, Sean Silva <chisophugis at gmail.com> wrote:

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


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?

-- Sean Silva


>
> -- 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/69f5d350/attachment.html>