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