[PATCH] D113582: [lld-macho] Support renaming of LSDA section

[Jez Ng via Phabricator via llvm-commits]

int3 created this revision.
int3 added a reviewer: lld-macho.
Herald added subscribers: ctetreau, mgrang.
Herald added a reviewer: gkm.
Herald added a project: lld-macho.
int3 requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Previously, our unwind info finalization logic assumed that the LSDA
section referenced by `__compact_unwind` was already finalized before
`__TEXT,__unwind_info` itself. However, that assumption could be broken
by the use of `-rename_section` -- it could be (and is) used to move
`__gcc_except_tab` it into a different segment later in the file.
(__TEXT is always the first non-zerofill segment, so any rename
basically guarantees that the section will be ordered after
`__unwind_info`.)

To handle this case, we compare LSDA relocations instead of their final
values in `UnwindInfoSection::finalize()`, and we actually relocate
those LSDAs in `UnwindInfoSection::writeTo()`. In order to do this, we
need an easy way to track which Symbol a given CUE corresponds to. My
solution was to change our `cuPtrVector` into a vector of indices, with
each index used for both the symbols vector (`symbolsVec`) as well as
the CUE vector (`cuVector`).

This change seems perf neutral. Numbers for linking chromium_framework
on my 16 core Mac Pro:

             base           diff           difference (95% CI)
  sys_time   1.248 ± 0.025  1.245 ± 0.026  [  -1.3% ..   +0.8%]
  user_time  3.588 ± 0.045  3.587 ± 0.037  [  -0.6% ..   +0.5%]
  wall_time  4.605 ± 0.069  4.595 ± 0.069  [  -1.0% ..   +0.5%]
  samples    42             26


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D113582

Files:
  lld/MachO/UnwindInfoSection.cpp
  lld/MachO/UnwindInfoSection.h
  lld/test/MachO/compact-unwind.s

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D113582.386220.patch
Type: text/x-patch
Size: 22329 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211110/1afc4154/attachment.bin>