[PATCH] D144999: [RFC][MC][MachO]Only emits compact-unwind format for "canonical" personality symbols. For the rest, use DWARFs.

James Y Knight via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 28 15:14:10 PST 2023


jyknight added a comment.

So, sigh -- I've just realized this will need a (small) linker change, as well. Currently, we (both LLD and LD64) encode the personality function in the compact-unwind even for unwind infos marked MODE_DWARF.

I believe this is unnecessary, however: in libunwind, `getInfoFromCompactEncodingSection` is called first, and if it says "use dwarf", then it calls `getInfoFromDwarfSection` which calls `getInfoFromFdeCie`, which will overwrite `_info.handler` with the personality retrieved from the DWARF CIE. (Though, I haven't yet verified it functions as I believe it does with a real-world test).

To fix this, the linker should skip encoding a personality for the compact-unwind entry when the compact-unwind is MODE_DWARF. In lld, that's probably most easily done by setting cu.personality = nullptr instead of fde.personality in UnwindInfoSectionImpl::relocateCompactUnwind. In ld64, I dunno, but might be easier to implement by just skipping such DWARF entries in the pass that assigns the personality-indices.

In D144999#4159609 <https://reviews.llvm.org/D144999#4159609>, @int3 wrote:

> Why not let the end user decide whether to enable DWARF unwind by passing `-femit-dwarf-unwind`?

One issue is that we need to emit ONLY dwarf-unwind for those functions which use nonstandard personalities, while femit-dwarf-unwind enables emitting both compact-unwind and dwarf unwind.
Another issue is that this is an assembler flag, and especially in LTO mode, we would not want to use dwarf unwind on ALL functions, only those using a non-standard personality.

>> As a result, any system that needs custom-personality will run into a problem.
>
> This isn't true; it will only run into a problem if it is using all 3 of the canonical personalities, which isn't always the case. E.g. we definitely link Rust programs successfully even without this

Yes, but getting an error when you add an additional object to the link is not a good experience. The default behavior should be to produce reliably-linkable code. But I think it'd be OK to add an LLVM MC option `-compact-unwind-all-personalities` as an 'expert' option, if you somehow know that in your project, you won't overflow personalities.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144999/new/

https://reviews.llvm.org/D144999



More information about the llvm-commits mailing list