Re: Unaligned access trade-offs for SFrame FRE layout

On Wed, Sep 17, 2025 at 05:12:51PM -0400, Steven Rostedt wrote:
> On Mon, 15 Sep 2025 23:05:09 -0700
> Fangrui Song <[email protected]> wrote:
> 
> > From a linker and binary utilities perspective, I'd even suggest  
> > adopting a universal little-endian format regardless of the target
> > system's native endianness.
> > This would eliminate the need for endianness templates in the C++ code
> > and simplify toolchain implementation across platforms.
> 
> Thinking about this more, I have some concerns with having the SFrame
> section being always in little endian format.
> 
> 1. Is there precedent for an ELF section to be in a different endian than
>    what the ELF file is designated as? If not, I don't think we should be
>    adding one.

Quoting the ELF gABI:
Byte e_ident[EI_DATA] specifies the encoding of both the data
structures used by object file container and data contained in object
file sections.

> 
> 2. This moves the computation from build /link time to run time. As a kernel
>    developer, whenever possible, if we can have longer build times for
>    quicker runtime we go ahead and do that.
> 
> 3. It makes the kernel code a bit more complicated.
> 
> Basically, if we decide to have SFrames in little endian, then all big
> endian machines will be taking a hit at *every* stack trace! If you are
> doing one stack trace a millisecond, that means this hit happens 1000s of
> times a second. And that's for reading every item in the SFrame section.
> 
> We want the stack traces to be fast as possible as they will be slowing
> down the application that is being profiled. Doing byte swaps will likely
> have a noticeable impact.
> 
> I would strongly suggest keeping the SFrame values in the endian of the
> machine it will be running on.

I agree.

-- 
Alan Modra