[PATCH] D125645: [ARM SEH 3] [ARM] [MC] Add support for writing ARM WinEH unwind info

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo added a comment.

In D125645#3517116 <https://reviews.llvm.org/D125645#3517116>, @efriedma wrote:

> In D125645#3516998 <https://reviews.llvm.org/D125645#3516998>, @mstorsjo wrote:
>
>> In D125645#3516878 <https://reviews.llvm.org/D125645#3516878>, @efriedma wrote:
>>
>>> It looks like this doesn't include any directive to set the "F" bit in xdata,
>>
>> That's true. If we'd have unwind info splitting implemented, that bit would be set on the follow-up fragments, implicitly. Maybe there's a usecase for manually creating such unwind data though? I think that one can be added without much troubles later, if there's a concrete demand for it though...
>
> We would want this to split a function across multiple section (e.g. for hot/cold splitting).

Oh, right, true.

>> (On that note, when rereading the docs about the "F" bit, I'm left wondering how that's supposed to work. If we have a huge function, and describe a prologue-less fragment in the middle of the function - how will unwinding from it work, when there's no prologue opcodes in that fragment to use for unwinding, if unwinding starts from outside of any potential epilogue in it, as there also can be fragments without epilogues?)
>
> I'm pretty sure the idea is that you still emit the prologue opcodes from the original prologue.  The "F" bit just means that the prologue is not part of the current fragment.  (For AArch64, this idea was generalized with the "c_end" opcode.)

Ah, yes. (I just rechecked this with my empirical tests with RtlVirtualUnwind too.)

Would this look like a reasonable way of handling it?

  myfragment:
      .seh_proc myfragment
      .seh_save_regs {r4-r7,lr}
      .seh_stackalloc 1234
      .seh_endprologue_fragment
      // fragment code
      .seh_startepilogue
      // regular epilogue

Thus we'd pile up the phantom prologue opcodes at the start, and end it with an `. seh_endprologue_fragment` (which also implies that the opcodes aren't expected to exactly match the range between `.seh_proc` and `.seh_endprologue_fragment`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D125645