[llvm] [Object] Parsing and dumping of SFrame FDEs (PR #149828)
Pavel Labath via llvm-commits
llvm-commits at lists.llvm.org
Mon Jul 21 07:54:44 PDT 2025
================
@@ -19,24 +19,37 @@ namespace object {
template <endianness E> class SFrameParser {
public:
- static Expected<SFrameParser> create(ArrayRef<uint8_t> Contents);
+ static Expected<SFrameParser> create(ArrayRef<uint8_t> Contents,
+ uint64_t SectionAddress);
const sframe::Preamble<E> &getPreamble() const { return Header.Preamble; }
const sframe::Header<E> &getHeader() const { return Header; }
+ Expected<ArrayRef<uint8_t>> getAuxHeader() const;
+
bool usesFixedRAOffset() const {
return getHeader().ABIArch == sframe::ABI::AMD64EndianLittle;
}
bool usesFixedFPOffset() const {
return false; // Not used in any currently defined ABI.
}
+ using FDERange = ArrayRef<sframe::FuncDescEntry<E>>;
+ Expected<FDERange> fdes() const;
+
+ // Decodes the start address of the given FDE, which must be one of the
+ // objects returned by the `fdes()` function.
+ uint64_t getAbsoluteStartAddress(typename FDERange::iterator FDE) const;
+
private:
ArrayRef<uint8_t> Data;
+ uint64_t SectionAddress;
const sframe::Header<E> &Header;
- SFrameParser(ArrayRef<uint8_t> Data, const sframe::Header<E> &Header)
- : Data(Data), Header(Header) {}
+ SFrameParser(ArrayRef<uint8_t> Data, uint64_t SectionAddress, const sframe::Header<E> &Header)
+ : Data(Data), SectionAddress(SectionAddress), Header(Header) {}
+
+ uint64_t getFDEBegin() const { return sizeof(Header) + Header.AuxHdrLen + Header.FDEOff; }
----------------
labath wrote:
@ibhagatgnu, I'm a little but unsure about this part. This is the interpretation I get from the specification, and I think it matches [this](https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=libsframe/sframe.c;h=824d1fd7ed99e28f07f2e3f935080228efa38b24;hb=HEAD#l497) endiannes-flipping code in libsframe. However, that's not what happens in the actual [parsing code](https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=libsframe/sframe.c;h=824d1fd7ed99e28f07f2e3f935080228efa38b24;hb=HEAD#l961). Can I assume the last part to be an omission/bug?
https://github.com/llvm/llvm-project/pull/149828
More information about the llvm-commits
mailing list