<div dir="ltr">Rafael, here is a repro.tar to look at: <a href="https://reviews.llvm.org/F3100177">https://reviews.llvm.org/F3100177</a><div><br></div><div>The attached foo.diff adds a print which shows the issue.</div><div><br></div><div>```</div><div><div>NAME: sleep SYMINDEX: 2</div><div>NAME: sched_yield SYMINDEX: 1</div><div>NAME: __libc_start_main SYMINDEX: 0</div><div>```</div><div><br></div><div><div>`readelf --relocs` Shows that we create :</div><div><br></div><div>...</div><div><div>000000255110  002900000007 R_X86_64_JUMP_SLO 0000000000254410 __xstat@GLIBC_2.2.5 + 0</div><div>000000255118  001e00000007 R_X86_64_JUMP_SLO 0000000000254420 __fxstat@GLIBC_2.2.5 + 0</div><div>000000255120  000000000007 R_X86_64_JUMP_SLO                    0</div><div>000000255128  002c00000007 R_X86_64_JUMP_SLO 0000000000254440 uname@GLIBC_2.2.5 + 0</div><div>000000255130  001b00000007 R_X86_64_JUMP_SLO 0000000000254450 getenv@GLIBC_2.2.5 + 0</div></div><div>...</div></div><div><br></div><div>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.</div><div><br></div><div>-- Sean Silva</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 3:12 AM, Carlo Kok <span dir="ltr"><<a href="mailto:ck@remobjects.com" target="_blank">ck@remobjects.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
On 2017-02-22 08:34, Sean Silva wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
<br>
On Tue, Feb 21, 2017 at 2:05 PM, Rafael Avila de Espindola via llvm-dev<br></span>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.or<wbr>g</a>>> wrote:<span class="gmail-"><br>
<br>
    Carlo Kok <<a href="mailto:ck@remobjects.com" target="_blank">ck@remobjects.com</a> <mailto:<a href="mailto:ck@remobjects.com" target="_blank">ck@remobjects.com</a>>> writes:<br>
<br>
    > On 2017-02-21 20:33, Rafael Avila de Espindola wrote:<br>
    >>> Input files:<br>
    >>> <a href="https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/8yn3<wbr>dggx05atn47/binLinux.zip?dl=0</a><br>
    <<a href="https://www.dropbox.com/s/8yn3dggx05atn47/binLinux.zip?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/8yn<wbr>3dggx05atn47/binLinux.zip?dl=0</a><wbr>><br>
    >><br>
    >> If you pass --reproduce foo.tar to lld it will create a foo.tar file<br>
    >> with all that is needed to reproduce the link.<br>
    >><br>
    >> Can you also share how you created the various .o files? If so I might<br>
    >> be able to try reducing the issue.<br>
    ><br>
    > It's created by my own compiler.<br>
    ><br>
    > <a href="https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/rmky<wbr>qks4lnr85rz/foo.tar?dl=0</a><br>
    <<a href="https://www.dropbox.com/s/rmkyqks4lnr85rz/foo.tar?dl=0" rel="noreferrer" target="_blank">https://www.dropbox.com/s/rmk<wbr>yqks4lnr85rz/foo.tar?dl=0</a>><br>
    ><br>
    > My biggest problem is that I have no idea where I can start trying to<br>
    > narrow it down, on the so side, or on the executable side, the error is<br>
    > rather strange to begin with.<br>
<br>
    I would suggest setting up a script that links each .so and executable<br>
    with either lld or bfd. That way you should be able to find which link<br>
    causes the problem.<br>
<br>
    After that start reducing the problem. If it was c++, you would run<br>
    delta on the .ii file checking that the bfd linked program/library works<br>
    and that the lld linked one fails to load.<br>
<br>
<br>
Carlo seems to be passing --lto-O0 so bugpoint might be a viable<br>
alternative as well if the input is bitcode.<br>
<br>
-- Sean Silva<br>
</span></blockquote>
<br>
<br>
Should anyone ever get this, Sean Silva found this:<br>
<br>
declare extern_weak hidden void @__libc_start_main(i32 (i32, i8**, i8**)*, i32, i16**, i32 (i32, i8**, i8**)*, void ()*)<br>
<br>
triggered a rogue relocation to (0). Making it non hidden fixes this.<br>
<br>
Rafael, weird thing is, gnu ld is perfectly fine with this, so not sure if this is a bug.<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
</blockquote>
<br>
-- <br>
Carlo Kok<br>
RemObjects Software<br>
</div></div></blockquote></div><br></div></div></div>