PR/59070
Details
- Reviewers
jyknight int3 - Group Reviewers
Restricted Project - Commits
- rG65226d3f1f53: [lld-macho] Fix bug in CUE folding that resulted in wrong unwind table.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for tracking this down!!
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
182 | nit: rm blank line | |
183 | nit 1: I think "largest" is more descriptive than "final" (plus "final" often has temporal-ordering connotations, e.g. InputSection::isFinal). Also maybe unwindAddressBoundary or cuAddressBoundary might be a better name for the variable, for similar reasons? nit 2: I don't think "this should covered folded entries as well" is a super clear explanation; I thought about how to elaborate on it, but then I think maybe it's better to let the reader figure that out by reading the comments in the implementation. I guess it's okay if you want to keep that line though. | |
464 | "remember" usually means "recall", rather than record/save. | |
658 | this is now unused | |
659 | I'm not entirely sure why, but this is what ld64 does | |
lld/test/MachO/compact-unwind-folding-bug.s | ||
2 | just to be clear, 'remove boilerplate' will include removing all the LSDA stuff, yes? we don't need to have a file that repros the actual no-catch bug, just something that checks that the last address of a bunch of folded CUEs is correct |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
659 | Adding 1 does make sense. This value is the start of the "next function", so it's an exclusive bound, and you want the final byte of the function to actually be included in the range. |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
659 | That was my initial thought too, but shouldn't adding the length already make it an exclusive bound? |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
659 | hmm yeah, looks like LD64 does add 1. (here and a couple of lines up in the secondLevelPages loop too). |
Thanks!
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
183 | thanks for changing the comments! thoughts on the variable rename? | |
641 | ||
659 | or possibly to work around a mistake in the runtime unwinder... hard to say without carefully reading its implementation. @oontvoo I'll leave it up to you whether you want to leave the +1 in. We could certainly omit it and see if it causes any problems in practice. | |
lld/test/MachO/compact-unwind-folding-bug.s | ||
3 | How about
I'm also wondering if the test file name can have something more specific than "folding bug"... maybe compact-unwind-tail-folding.s? Because it's not a bug in folding in general, only when the fold happens at the tail entries of the CUE array. | |
20 | (alternatively you could omit it entirely, MC emits stuff into .text by default) | |
25–28 | can we remove more boilerplate? (likewise for the other functions) | |
57–60 | why do we need this? |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
183 | changed to cueEndBoundary ? | |
659 | I'll remove the +1 since it seems wrong (ie., if there happens to be stuff after the last entry taht *shouldn't* be in it, then the table would still include it.) Also speaking of "strange", there seems to be another edge case here. I've added the test case below. Should we replicate this or not? (my guess is no, but /shrug) | |
lld/test/MachO/compact-unwind-folding-bug.s | ||
3 | How about just compact-unwind-folding.s? | |
25–28 | We probably could - but slightly prefer that these symbols refer to each other (so that they don't look like they're all unused) |
lld/MachO/UnwindInfoSection.cpp | ||
---|---|---|
183 | sounds good! | |
lld/test/MachO/compact-unwind-folding-bug.s | ||
3 | sgtm! | |
lld/test/MachO/compact-unwind-foldings.s | ||
7 ↗ | (On Diff #476973) | |
59–60 ↗ | (On Diff #476973) | this makes sense to me, and I think we can keep our deviation from ld64's behavior here |
61 ↗ | (On Diff #476973) | is this directive necessary? |
85–86 ↗ | (On Diff #476973) | both ld64 and LLD do include an entry (with encoding 0x0) for this, right? I'm not sure there's a way to *not* include _d here, since if there isn't an entry with 0x0 encoding, then the unwinder just uses the CUE at the most recent preceding address. So I think ld64 is working correctly here |
88 ↗ | (On Diff #476973) | ditto |
lld/test/MachO/compact-unwind-foldings.s | ||
---|---|---|
85–86 ↗ | (On Diff #476973) | right - when _d is in the middle of the range, we can't exclude it. |
nit: rm blank line