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

[Carlo Kok via llvm-dev]

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