public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* Missing alignment in SFrame spec
@ 2023-04-28  8:08 Florian Weimer
  2023-05-02  0:24 ` Indu Bhagat
  0 siblings, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2023-04-28  8:08 UTC (permalink / raw)
  To: Indu Bhagat; +Cc: binutils

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Missing alignment in SFrame spec
  2023-04-28  8:08 Missing alignment in SFrame spec Florian Weimer
@ 2023-05-02  0:24 ` Indu Bhagat
  2023-05-02  6:03   ` Florian Weimer
  0 siblings, 1 reply; 4+ messages in thread
From: Indu Bhagat @ 2023-05-02  0:24 UTC (permalink / raw)
  To: Florian Weimer; +Cc: binutils

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Missing alignment in SFrame spec
  2023-05-02  0:24 ` Indu Bhagat
@ 2023-05-02  6:03   ` Florian Weimer
  2023-05-03 17:37     ` Indu Bhagat
  0 siblings, 1 reply; 4+ messages in thread
From: Florian Weimer @ 2023-05-02  6:03 UTC (permalink / raw)
  To: Indu Bhagat; +Cc: binutils

* Indu Bhagat:

> 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.

Well, GAS seems to generate 8-byte-aligned .sframe sections (at least in
the 2.40-7.fc39 Fedora package).  So all this is a bit inconsistent.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Missing alignment in SFrame spec
  2023-05-02  6:03   ` Florian Weimer
@ 2023-05-03 17:37     ` Indu Bhagat
  0 siblings, 0 replies; 4+ messages in thread
From: Indu Bhagat @ 2023-05-03 17:37 UTC (permalink / raw)
  To: Florian Weimer; +Cc: binutils

On 5/1/23 11:03 PM, Florian Weimer via Binutils wrote:
> * Indu Bhagat:
> 
>> 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.
> 
> Well, GAS seems to generate 8-byte-aligned .sframe sections (at least in
> the 2.40-7.fc39 Fedora package).  So all this is a bit inconsistent.
> 

I will work on making the spec clear about alignment expectations for 
the .sframe section and the various definitions in the format.

> Thanks,
> Florian
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-05-03 17:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-28  8:08 Missing alignment in SFrame spec Florian Weimer
2023-05-02  0:24 ` Indu Bhagat
2023-05-02  6:03   ` Florian Weimer
2023-05-03 17:37     ` Indu Bhagat

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).