llvm-project.git/llvm/lib/BinaryFormat/SFrame.cpp, branch main Unnamed repository; edit this file 'description' to name the repository. Reapply "[Object] Parsing and dumping of SFrame Frame Row Entries" (#152650) (#152695) 2025-08-12T08:10:45+00:00 Pavel Labath pavel@labath.sk 2025-08-12T08:10:45+00:00 66aa46da6c2f18d8e7493bc2105abef0af4a7b98 This reapplies #152650 with a build fix for clang-11 (need explicit template parameters for ArrayRef construction) and avoiding the default-in-a-switch-covering-enum warning. It also adds two new tests. The original commit message was: 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). 
This reapplies #152650 with a build fix for clang-11 (need explicit
template parameters for ArrayRef construction) and avoiding the
default-in-a-switch-covering-enum warning. It also adds two new tests.

The original commit message was:

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).
 Revert "[Object] Parsing and dumping of SFrame Frame Row Entries" (#152650) 2025-08-08T06:29:58+00:00 Pavel Labath pavel@labath.sk 2025-08-08T06:29:58+00:00 7e8a251f751c47f31103db2975a34d1b7780d992 Reverts llvm/llvm-project#151301 - build breakage on multiple bots. 
Reverts llvm/llvm-project#151301 - build breakage on multiple bots.
 [Object] Parsing and dumping of SFrame Frame Row Entries (#151301) 2025-08-08T06:22:08+00:00 Pavel Labath pavel@labath.sk 2025-08-08T06:22:08+00:00 a82ca1b5603a4ed9598b784f703d908f32e970b8 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). 
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).
 [Object] Parsing and dumping of SFrame FDEs (#149828) 2025-07-30T09:23:35+00:00 Pavel Labath pavel@labath.sk 2025-07-30T09:23:35+00:00 ded255e56ee1f2ef27e85b013f572fca34ca57bc Also known as Function Description Entries. The entries occupy a contiguous piece of the section, so the code is mostly straight-forward. 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). 
Also known as Function Description Entries. The entries occupy a
contiguous piece of the section, so the code is mostly straight-forward.

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).
 [Object] Beginnings of SFrame parser and dumper (#147294) 2025-07-21T06:46:21+00:00 Pavel Labath pavel@labath.sk 2025-07-21T06:46:21+00:00 aa7ada1dfbe21a0c83474eb3de54e08eb607f8b8 This PR adds the SFrameParser class and uses it from llvm-readobj to dump the section contents. Currently, it only supports parsing the SFrame section header. Other parts of the section will be added in follow-up patches. llvm-readobj uses the same sframe flag syntax as GNU readelf, but I have not attempted match the output format of the tool. I'm starting with the "llvm" output format because it's easier to generate and lets us tweak the format to make it useful for testing the generation code. If needed, support for the GNU format could be added by overriding this functionality in the GNU ELF Dumper. For more information, see the [sframe specification](https://sourceware.org/binutils/wiki/sframe) and the related [RFC](https://discourse.llvm.org/t/rfc-adding-sframe-support-to-llvm/86900). 
This PR adds the SFrameParser class and uses it from llvm-readobj to
dump the section contents. Currently, it only supports parsing the
SFrame section header. Other parts of the section will be added in
follow-up patches.

llvm-readobj uses the same sframe flag syntax as GNU readelf, but I have
not attempted match the output format of the tool. I'm starting with the
"llvm" output format because it's easier to generate and lets us
tweak the format to make it useful for testing the generation code. If
needed, support for the GNU format could be added by overriding this
functionality in the GNU ELF Dumper.

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