[PATCH] D137368: [lld-macho] Overhaul map file code

[Jez Ng via Phabricator via llvm-commits]

int3 created this revision.
int3 added a reviewer: lld-macho.
Herald added projects: lld-macho, All.
int3 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D137368

Files:
  lld/MachO/MapFile.cpp
  lld/test/MachO/map-file.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D137368.473059.patch
Type: text/x-patch
Size: 15099 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20221103/56fc3a7c/attachment.bin>