[all-commits] [llvm/llvm-project] a82ca1: [Object] Parsing and dumping of SFrame Frame Row E...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a82ca1b5603a4ed9598b784f703d908f32e970b8
      https://github.com/llvm/llvm-project/commit/a82ca1b5603a4ed9598b784f703d908f32e970b8
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2025-08-08 (Fri, 08 Aug 2025)

  Changed paths:
    M llvm/include/llvm/BinaryFormat/SFrame.h
    M llvm/include/llvm/Object/SFrameParser.h
    M llvm/lib/BinaryFormat/SFrame.cpp
    M llvm/lib/Object/SFrameParser.cpp
    M llvm/test/tools/llvm-readobj/ELF/sframe-fde.test
    A llvm/test/tools/llvm-readobj/ELF/sframe-fre.test
    M llvm/tools/llvm-readobj/ELFDumper.cpp

  Log Message:
  -----------
  [Object] Parsing and dumping of SFrame Frame Row Entries (#151301)

The trickiest part here is that the FREs have a variable size, in two
(or three?) dimensions:
- the size of the StartAddress field. This determined by the FDE they
are in, so it is uniform across all FREs in one FDE.
- the number and sizes of offsets following the FRE. This can be
different for each FRE.

While vending this information through a template API would be possible,
I believe such an approach would be very unwieldy, and it would still
require a sequential scan through the FRE list. This is why I'm
implementing this by reading the data into a common data structure using
the fallible iterator pattern.

For more information about the SFrame unwind format, see the
[specification](https://sourceware.org/binutils/wiki/sframe) and the
related
[RFC](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900).



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