summaryrefslogtreecommitdiff
path: root/llvm/lib/BinaryFormat/SFrame.cpp
AgeCommit message (Collapse)Author
2025-08-12Reapply "[Object] Parsing and dumping of SFrame Frame Row Entries" (#152650) ↵Pavel Labath
(#152695) 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).
2025-08-08Revert "[Object] Parsing and dumping of SFrame Frame Row Entries" (#152650)Pavel Labath
Reverts llvm/llvm-project#151301 - build breakage on multiple bots.
2025-08-08[Object] Parsing and dumping of SFrame Frame Row Entries (#151301)Pavel Labath
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).
2025-07-30[Object] Parsing and dumping of SFrame FDEs (#149828)Pavel Labath
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).
2025-07-21[Object] Beginnings of SFrame parser and dumper (#147294)Pavel Labath
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).