]> git.feebdaed.xyz Git - 0xmirror/binutils-gdb.git/commit
libsframe: implement an internal-only SFrame FDE representation
authorIndu Bhagat <indu.bhagat@oracle.com>
Wed, 24 Dec 2025 08:41:02 +0000 (00:41 -0800)
committerIndu Bhagat <indu.bhagat@oracle.com>
Wed, 24 Dec 2025 08:41:02 +0000 (00:41 -0800)
commit705a1d47a48ff53213fc9bd9225b345087b58146
treece5f2bad977d676db9822b056bc325d6c23ddd88
parent6bd2eada301d0d0946cf8831adb9b4e4cb1864ba
libsframe: implement an internal-only SFrame FDE representation

Up until now, libsframe has used the same SFrame FDE representation as
the on-disk representation (sframe_func_desc_entry).  The choice made by
the author of the library, back when it was first contributed, perhaps
sufficed the needs then.  But looking forward, we need to be able to
allow reading and dumping out of not just sections with version
SFRAME_VERSION_2 but also future supported versions.

Note that libsframe did not (and still does not) expose the SFrame FDE
representation in any public APIs;  doing so is not recommended.

For the path forward, create an internal-only SFrame FDE representation
(sframe_func_desc_entry_int).  libsframe now keeps all in-memory FDEs of
type sframe_func_desc_entry_int.  Doing so means instead of memcpy, we
need to resort to member-by-member mapping.  This can be seen in
sframe_fde_tbl_init (read time) and the new function
sframe_encoder_write_fde (write time).

Other than that, replace out the previous direct interaction with
on-disk format when:
  - flipping SFrame contents before decoding them in sframe_decode.
  - flipping SFrame contents before writing them out in sframe_encode.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/sframe.c