[MachO] Don't fold compact unwind entries with LSDA

[smeenai]

Summary

Folding them will cause the unwinder to compute the incorrect function
start address for the folded entries, which in turn will cause the
personality function to interpret the LSDA incorrectly and break
exception handling.

You can verify the end-to-end flow by creating a simple C++ file:

void h();
int main() { h(); }

and then linking this file against the liblsda.dylib produced by the
test case added here. Before this change, running the resulting program
would result in a program termination with an uncaught exception.
Afterwards, it works correctly.

[thevinster]

Some minor comments. Overall, LGTM, I'll leave it to people more familiar with the code to stamp.

lld/MachO/UnwindInfoSection.cpp

466

In what scenario would we have compact unwind entries without LSDA? I'm wondering if this is now effectively a condition that will never be hit and thus dead code now.

lld/test/MachO/compact-unwind-lsda-folding.s

3

Should we also have a test for when they can be folded?

[smeenai]

lld/MachO/UnwindInfoSection.cpp

466

It's pretty common to have compact unwind entries without LSDA :) You only need LSDA when you have language-specific actions to take during unwinding, e.g. running destructors or a catch statement. In the test below, you'll notice that g and h have indices 0 and 1 in the LSDA descriptors but 1 and 2 in the second level indices; that's because f has the compact unwind entry at index 0 but no LSDA.

lld/test/MachO/compact-unwind-lsda-folding.s

3

compact-unwind-generated.test handles that via tools/validate-unwind-info.py.