[llvm] [llvm] Win x64 Unwind V2 1/n: Mark beginning and end of epilogs (PR #110024)

[Pedro Miguel Justo via llvm-commits]

pmsjt wrote:


> Ah, I wasn't aware of this (although I haven't spent much time around the x64 unwinding formats either, I've mostly looked at the ARM and ARM64 formats). Does code generated by LLVM fulfill these criteria at the moment, and are those rules documented anywhere?

Canonical epilog rules, which also apply to V2:
https://learn.microsoft.com/en-us/cpp/build/prolog-and-epilog?view=msvc-170#epilog-code

> As a side note - if dealing with functions that doesn't abide by these rules (either compiler generated that doesn't know about these rules, or custom assembly); one can't expect to get correct unwinding from within the epilog of course. But I wonder if there's a risk if the heuristic for guessing whether we're in body or epilog does an incorrect guess? (And I guess that whole issue is fixed by this V2 format.)

It is unlikely that V2 will solve anything that is already broken in V1. The V2 rules are as strict (technically more) than the V1.

> So, iirc for the x64 unwind format, each unwind opcode also contains an offset - so you can have a prolog that intermixed with other instructions, that don't have any opcode. (This requires NOP unwind opcodes on ARM/ARM64, but on x64, due to the offsets, isn't needed there.) How does this work for assuming the epilog is a symmetrical mirror of the prolog? Assuming that the epilog is tightly packed, given normative instruction lengths for each unwind opcode?

The offsets are not used for epilog processing. The epilog is assumed to be compact, without any unrelated instructions in the middle. So not strictly symmetrical. Just the order of UWOPs is symmetrical. There are also other details. For example, if there are any SAVE_NON_VOLATILE and ALLOC in the prolog, these are assumed to been executed already at the start of the epilog. In other words, the instruction prior to the start of the epilog is expected to be the (single) instruction truncating the non-push/pop portion of the stack.

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