[PATCH] D86527: [3/5] [MC] [Win64EH] Produce well-formed xdata records when info is missing

Martin Storsjö via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 26 14:52:03 PDT 2020


mstorsjo added a comment.

In D86527#2240344 <https://reviews.llvm.org/D86527#2240344>, @efriedma wrote:

> I don't understand how we end up in this position in the first place.  Why does .seh_handlerdata need to trigger the emission of unwind data?

Because `.seh_handlerdata` changes the active section to the xdata section, emits the unwind info record, letting you append handler specific data which is supposed to follow directly after the unwind data itself. (See the testcase in this patch.)

> Why is it okay if the resulting unwind data is nonsense?

Well it's at least parsable, but nonsense, which is better than unparseable records.

But I don't believe this case, `.seh_handlerdata` without any valid opcodes really happens in the wild - so the exact handling doesn't matter much. Functions with just `.seh_proc`/`.seh_endproc` do occur though, but those are easy to omit and handle cleanly (which the current revision if the patch does).

For the contrieved `.seh_handlerdata` case, we could avoid outputting the unwind info itself, leave the orphaned handler specific data in the section, and not hook up the pdata entry. Can we output warnings from this layer?


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

https://reviews.llvm.org/D86527



More information about the llvm-commits mailing list