[all-commits] [llvm/llvm-project] 220116: [llvm] Win x64 Unwind V2 2/n: Support dumping UOP_...

[Daniel Paoliello via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 2201164477982c2bd20fa2e925f567585c390805
      https://github.com/llvm/llvm-project/commit/2201164477982c2bd20fa2e925f567585c390805
  Author: Daniel Paoliello <danpao at microsoft.com>
  Date:   2025-01-13 (Mon, 13 Jan 2025)

  Changed paths:
    M llvm/include/llvm/Support/Win64EH.h
    A llvm/test/tools/llvm-objdump/COFF/win64-unwindv2.yaml
    M llvm/test/tools/llvm-readobj/COFF/unwind-x86_64-image.yaml
    M llvm/tools/llvm-objdump/COFFDump.cpp
    M llvm/tools/llvm-readobj/Win64EHDumper.cpp
    M llvm/tools/llvm-readobj/Win64EHDumper.h

  Log Message:
  -----------
  [llvm] Win x64 Unwind V2 2/n: Support dumping UOP_Epilog (#110338)

Adds support to objdump and readobj for reading the `UOP_Epilog` entries
of Windows x64 unwind v2.

`UOP_Epilog` has a weird format:

The first `UOP_Epilog` in the unwind data is the "header":
* The least-significant bit of `OpInfo` is the "At End" flag, which
signifies that there is an epilog at the very end of the associated
function.
* `CodeOffset` is the length each epilog described by the current unwind
information (all epilogs have the same length).

Any subsequent `UOP_Epilog` represents another epilog for the current
function, where `OpInfo` and `CodeOffset` are combined to a 12-bit value
which is the offset of the beginning of the epilog from the end of the
current function. If the offset is 0, then this entry is actually
padding and can be ignored.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications