Re: Missing alignment in SFrame spec

[Indu Bhagat <indu.bhagat@oracle.com>]

On 4/28/23 01:08, Florian Weimer wrote:
> The SFrame specification does not say anything explict about alignment.
> It uses ATTRIBUTE_PACKED, which strongly suggests alignment 1, but
> looking at the structures themselves, I think what you actually want is
> 4-byte alignment.
> 
> Thanks,
> Florian
> 

Hi Florian,

SFrame stack trace format is an unaligned on-disk format. IIUC, you 
suggest 4 byte alignment for all structs in SFrame format?

Yes, current SFrame FDE and SFrame FRE are 1-byte aligned.

I had reasoned about unaligned accesses previously when a bug showed up.

Memory READ side:
------------------
So far, we ran into some unaligned memory access issues earlier 
https://sourceware.org/bugzilla/show_bug.cgi?id=29856, but were fixable 
in libsframe, because the latter provides SFrame FREs via an in-memory 
abstraction sframe_frame_row_entry defined in include/sframe-api.h. The 
members of sframe_frame_row_entry are naturally aligned.

PR 29856 was about issues on the the memory READ side of SFrame FREs 
(Frame Row Entry). Now, I had also expected to see unaligned access when 
READ access to SFrame FDEs 
(sframe_func_desc_entry.sfde_func_start_address) was done by GNU 
ld/objdump. But when fixing the above bug, I did not see them. But I 
have it noted down to get to this sometime soon.

Memory WRITE side:
------------------
As for the accesses to SFrame header and its members, these should all 
be aligned memory accesses - both READ and WRITE. This is because SFrame 
header is the first entity in the section.  Its members have natural 
alignment.

On the WRITE side, GAS does a byte by byte write IIRC (GAS does not use 
libsframe APIs to write SFrame section). And as for GNU ld WRITE side, I 
checked (mentally) that unaligned accesses are either taken care of in 
libsframe or not present due to usage of memcpy.

So bottomline: I _think_ we are okay on the GNU as/ld READ and WRITE 
side as far as unaligned memory accesses are concerned. *EXCEPT*, SFrame 
Function Descriptor Entries (FDEs): there is an open item around access 
to sframe_func_desc_entry.sfde_func_start_address (and following members 
should exhibit the same problem), which I will check soon. I will double 
check for both READ and WRITE access to all SFrame FDE members when I do 
get to this.

Thank you for bringing it up. Does the above make sense ?

Indu