<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>