[all-commits] [llvm/llvm-project] 213dbd: [lld-macho] Overhaul map file code

[Jez Ng via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 213dbdbef0bad835abca0753f9e59b17dc2bcde2
      https://github.com/llvm/llvm-project/commit/213dbdbef0bad835abca0753f9e59b17dc2bcde2
  Author: Jez Ng <jezng at fb.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M lld/MachO/MapFile.cpp
    M lld/test/MachO/map-file.s

  Log Message:
  -----------
  [lld-macho] Overhaul map file code

The previous map file code left out was modeled after LLD-ELF's
implementation. However, ld64's map file differs quite a bit from
LLD-ELF's. I've revamped our map file implementation so it is better
able to emit ld64-style map files.

Notable differences:
* ld64 doesn't demangle symbols in map files, regardless of whether
  `-demangle` is passed. So we don't have to bother with
  `getSymbolStrings()`.
* ld64 doesn't emit symbols in cstring sections; it emits just the
  literal values. Moreover, it emits these literal values regardless of
  whether they are labeled with a symbol.
* ld64 emits map file entries for things that are not strictly symbols,
  such as unwind info, GOT entries, etc. That isn't handled in this
  diff, but this redesign makes them easy to implement.

Additionally, the previous implementation sorted the symbols so as to
emit them in address order. This was slow and unnecessary -- the symbols
can already be traversed in address order by walking the list of
OutputSections. This brings significant speedups. Here's the numbers
from the chromium_framework_less_dwarf benchmark on my Mac Pro, with the
`-map` argument added to the response file:

             base            diff           difference (95% CI)
  sys_time   2.922 ± 0.059   2.950 ± 0.085  [  -0.7% ..   +2.5%]
  user_time  11.464 ± 0.191  8.290 ± 0.123  [ -28.7% ..  -26.7%]
  wall_time  11.235 ± 0.175  9.184 ± 0.169  [ -19.3% ..  -17.2%]
  samples    16              23

(It's worth noting that map files are written in parallel with the
output binary, but they often took longer to write than the binary
itself.)

Finally, I did further cleanups to the map-file.s test -- there was no
real need to have a custom-named section. There were also alt_entry
symbol declarations that had no corresponding definition. Either way,
neither custom-named sections nor alt_entry symbols trigger special code
paths in our map file implementation.

Reviewed By: #lld-macho, Roger

Differential Revision: https://reviews.llvm.org/D137368


  Commit: 7f0779967f0690482c2cef70fc49e1381d32af1e
      https://github.com/llvm/llvm-project/commit/7f0779967f0690482c2cef70fc49e1381d32af1e
  Author: Jez Ng <jezng at fb.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M lld/MachO/MapFile.cpp
    M lld/test/MachO/map-file.s

  Log Message:
  -----------
  [lld-macho] Emit map file entry for compact unwind info

Just like ld64 does.

Reviewed By: #lld-macho, Roger

Differential Revision: https://reviews.llvm.org/D137369


  Commit: 1a2bc103bba04e8fba574c70c6201ba18ccc08ba
      https://github.com/llvm/llvm-project/commit/1a2bc103bba04e8fba574c70c6201ba18ccc08ba
  Author: Jez Ng <jezng at fb.com>
  Date:   2022-11-08 (Tue, 08 Nov 2022)

  Changed paths:
    M lld/MachO/InputFiles.cpp
    M lld/test/MachO/map-file.s

  Log Message:
  -----------
  [lld-macho] Fix bugs around EH_Frame symbols

While extending the map file to cover unwind info, I realized we had two
issues with our EH_Frame symbols:

1. Their size was not set
2. We would create two EH_Frame symbols per frame when we only needed
   one. This was because the Defined constructor would add the symbol
   itself to InputSection::symbols, but we were also manually appending
   the symbol to that same vector.

Note that ld64 prints "CIE" and "FDE for: <function>" instead of just
"EH_Frame", but I'm punting on that for now unless we discover that
users really depend upon it.

Reviewed By: #lld-macho, Roger

Differential Revision: https://reviews.llvm.org/D137370


Compare: https://github.com/llvm/llvm-project/compare/70633a8d55a5...1a2bc103bba0