[llvm-bugs] [Bug 51135] New: lld/mac symbol handling does not synergize with compiler-rt/lib/profile's _llvm_profile_filename

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51135

            Bug ID: 51135
           Summary: lld/mac symbol handling does not synergize with
                    compiler-rt/lib/profile's _llvm_profile_filename
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: MachO
          Assignee: unassignedbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: gkm at fb.com, jezreel at gmail.com,
                    llvm-bugs at lists.llvm.org, smeenai at fb.com

The way lld loads .a files is that it creates a `Lazy` symbol when parsing the
archive's symbol table, and if there's an Undefined later, it goes and fetches
the .o file in the .a file that defined that Lazy symbol.

In ld64, weak symbols in .o files win over weak symbols in .a files. This is
load-bearing for _llvm_profile_filename: That's defined in
compiler-rt/lib/profile/InstrProfilingFile.c as a weak symbol, but clang also
emits it into its output (also as a weak symbol, because it will be in every .o
file clang emits then) if you pass
`-fprofile-instr-generate=$PWD/profiles/%4m.profraw` (or a similar path) to
clang.

In ELF and COFF, I think this works because the driver passes libprofile at the
end of the link line (cf `ToolChain::addProfileRTLibs()`).

(Also, ELF seems to have to have a "undefined is weak ref" bit for undefineds
and uses that for things, e.g. https://reviews.llvm.org/rG8614c566e2b535
https://reviews.llvm.org/rGb2a5cafb3 etc, but not sure if that's relevant for
this bug -- I think it's just the ordering really.)

On MachO, the profile runtime is passed _first_ because of
https://reviews.llvm.org/D35385 , because apparently _llvm_profile_filename is
supposed to be ignored if it's in a dylib (!). So the desired search order for
it is apparently:

1. In .o files of the executable
2. In the runtime .a file
3. (In dylibs)

And there's no super great way to express this. Putting the runtime first makes
things work with ld64, but breaks normal operation even in the absence of
dylibs with lld.


Fix ideas:

1. Let lld always process .o files before other files. This might be
   performance-positive too since:
    a) might use the disk cache better
    b) might lead to loading fewer files from .a files if .o files contain
stuff
  ...but this is likely to have all kinds of subtle effects. If we end up doing
  this, we probably want to do it for all ports (?)

2. Let weak symbols remember if they came from a shared library, and let
   weak symbols not from a shared library win over weak symbols from a shared
   library. This should match ld64 semantics, but it means we'll generally
over-
   load object files from static libraries (which is bad for perf, and it also
   means we might load symbols that ld64 doesn't load, if the .o file initially
   loaded by the weak that we later discard happens to contain other symbols)

3. Come up with some other solution to the problem
https://reviews.llvm.org/D35385
   tries to solve, or decide that this kind of problem is a bug in the build
   system of projects hitting it and not something that clang should try to
   prevent and just revert that change.


3 seems easiest and cleanest, but https://reviews.llvm.org/D35385 probably was
done for some reason, so maybe we shouldn't just undo it.

1 abstractly sounds like it might be a good change to me, but it's also a bit
scary since it's a large and subtle change.

2 feels a bit like a kludge.


(ps: Reproing this currently requires patching in a local patch for issue
50760.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210719/b5053cde/attachment-0001.html>