<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 22, 2017 at 3:47 AM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Rafael, here is a repro.tar to look at: <a href="https://reviews.llvm.org/F3100177" target="_blank">https://reviews.llvm.org/<wbr>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></div></blockquote><div><br></div><div><br></div><div>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?</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span><div><div class="h5"><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="m_9033426847668944981gmail-"><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="m_9033426847668944981gmail-">
<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="m_9033426847668944981gmail-"><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="m_9033426847668944981gmail-HOEnZb"><div class="m_9033426847668944981gmail-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></div></div>
</blockquote></div><br></div></div>