[llvm-dev] lld symbol choice for symbol present in both a shared and a static library, with and without LTO

[Eli Friedman via llvm-dev]

From: Teresa Johnson <tejohnson at google.com>
Sent: Monday, June 17, 2019 6:37 AM
To: Rui Ueyama <ruiu at google.com>
Cc: Eli Friedman <efriedma at qualcomm.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] lld symbol choice for symbol present in both a shared and a static library, with and without LTO



On Mon, Jun 17, 2019 at 4:15 AM Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On Sat, Jun 15, 2019 at 4:58 AM Eli Friedman via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:

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?

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

I believe this is going to be specific to builtin functions. The reason is that the LTO link is fed by bitcode files, which at this point have references to the llvm intrinsic, not the library call. So the linker, which invokes the LTO compilation and provides the symbol resolutions, does not see any call to e.g. "memcpy". Later, in the LTO backends, the intrinsic gets turned into something, depending on the compiler's heuristics. This something could be an inline expansion of memcpy, or a regular call to memcpy.

Yes, this specifically applies to builtin functions, as far as I can tell.

For these libcalls, to avoid this behavior build with -fno-builtin-memcpy (or other libcall name), or more generally, -fno-builtin or -ffreestanding to block them all.

Unfortunately, this doesn’t work for _Unwind_Resume, which is the symbol that’s actually causing the issue in the scenario I’m looking at.
-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190617/648186ca/attachment.html>