[llvm-dev] [lld] elf linker creates undefined empty symbol
Carlo Kok via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 22 03:12:12 PST 2017
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
> >> 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
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.
More information about the llvm-dev