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

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.


-- 
Carlo Kok
RemObjects Software

It's scary to run the binary on my machine (and I don't have a sandbox
at
the moment), so I cannot actually run it, but there are a few things you
can do.

First of all, "symbol lookup error" is not LLD's error message.
It's likely
an error message of the dynamic linker. Try running it with `LD_VERBOSE=1
LD_TRACE_LOADED_OBJECTS=1` or something. Refer `man ld.so` for other
dynamic linker debug options.

On Tue, Feb 21, 2017 at 1:22 PM, Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> 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.
>
>
> --
> Carlo Kok
> RemObjects Software
> _______________________________________________
> 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/c6906347/attachment.html>

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.

Cheers,
Rafael

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>