<div dir="ltr"><div dir="ltr">On Sat, Jun 15, 2019 at 4:58 AM Eli Friedman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_8261370493228121197WordSection1">
<p class="MsoNormal">I filed <a href="https://bugs.llvm.org/show_bug.cgi?id=42273" target="_blank">
https://bugs.llvm.org/show_bug.cgi?id=42273</a> last night, about an inconsistency between LTO and non-LTO workflows.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The basic scenario is that we have an object file which calls a function â€œfoo”, a static library that provides an implementation of â€œfoo”, and a shared library that also provides an implementation of â€œfoo”.  Currently, whether lld chooses
 the symbol from the static library or the shared library depends on the order the files are specified on the command-line.  For â€œobj.o static.a shared.so”, or â€œstatic.a obj.o shared.so”, lld chooses the symbol from the static library. For any other order,
 it chooses the symbol from the shared library.  Is this the expected behavior?  (As far as I can tell, this matches binutils ld except for the â€œstatic.a obj.o shared.so” case.)</p></div></div></blockquote><div><br></div><div>This is what I expected. When lld visits an object file A and find an undefined symbol, and there's a file B that appears before the object file in the command line that defines the symbol, then B gets linked. If there's more than one file that define the symbol, the leftmost one is chosen.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_8261370493228121197WordSection1">
<p class="MsoNormal">If â€œobj.o” is built with LTO enabled, and the function is specifically a runtime function, the behavior is different.  For example, suppose the IR contains a call to â€œllvm.memcpy”, and the generated code eventually calls â€œmemcpy”.  Or suppose
 the IR contains a â€œresume” instruction, and the generated code eventually calls â€œ_Unwind_Resume”.  In this case, the choice is different: lld always chooses the â€œmemcpy” or â€œ_Unwind_Resume” from the shared library, ignoring the order the files are specified
 on the command-line.  Is this the expected behavior?</p></div></div></blockquote><div><br></div><div>That's not expected, but I suspect that that only occurs when you use a builtin function like memcpy. Does this happen when you define some random function like "foo"?</div></div></div>