[clang] [llvm] [win][x64] Unwind v2 3/n: Add support for requiring unwind v2 to be used (equivalent to MSVC's /d2epilogunwindrequirev2) (PR #143577)

[via llvm-commits]

panagiotidisc wrote:

>Future work: attempting to chain unwind info across multiple tables if there are too many unwind codes due to epilogs and adding a heuristic to detect if an epilog will be too far from the end of the function.

The epilog offset is from the end of the RuntimeFunction, not the end of the whole procedure (which is ill-defined especially in the case of discontiguous functions)

> I'm a little concerned about the wording of the errors here. The "too many epilogues" and "too many opcodes" errors should say that it's not yet implemented, or something, so it's clear it's a limitation of the compiler. Maybe try to suggest a workaround of some sort... maybe mention tail-calls since that's the most likely culprit.

There are limitations by the format. An individual UnwindInfo may have up to 0xFF UnwindCode words, and there is a 0xFF size restriction on prologues, and 0xFFF offset limitation from end of RuntimeFunction on epilogues. In such (unlikely) cases, the procedure must be split into multiple RuntimeFunction/UnwindInfo.

> The other conditions shouldn't occur at all: there's no reason to generate an epilogue that doesn't match the prologue, as far as I know.


With chained UnwindInfo, it is possible to save additional non-vol registers multiple times in the body of the function (multiple shrink-wrapping). Instructions restoring these registers may then be immediately be followed by an epilogue, so it may catch an erroneous placement of SEH_BeginEpilogue. 

Another issue that arises is correctly recording in which chained UnwindInfo of the procedure which additional saves must be assumed, either by A) chaining with the UnwindInfo that did the save, or by B) having these unwind codes with offset 00 (eg. `00: SAVE_NONVOL, register=rdi offset=0x90`), and chaining with another UnwindInfo. Msvc seems to do chaining and shrink-wrapping based on the control flow graph, and some rules that I unfortunately haven't quite figured out.

Additional note:
RuntimeFunctions don't have to be one-to-one with UnwindInfo. msvc shares UnwindInfo between RuntimeFunctions, as long as they don't have PUSH_MACHFRAME, or Unwind flags: CHAININFO

https://github.com/llvm/llvm-project/pull/143577