Unaligned access trade-offs for SFrame FRE layout

[Steven Rostedt]

On Mon, 15 Sep 2025 23:05:09 -0700
Fangrui Song <maskray@sourceware.org> 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.

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.

-- Steve