On 7/22/25 12:17 PM, Steven Rostedt wrote:

On Tue, 22 Jul 2025 20:56:47 +0200
"Jose E. Marchesi" [off-list ref] wrote:

quoted

I think glibc could "register" loaded SFrame data by just pointing the
kernel to the VM address where it got loaded, "you got some SFrame
there".  Starting from that address it is then possible to find the
referred code locations just by applying the offsets, without needing
any additional information nor ELF foobar...

Or thats how I understand it.  Indu will undoubtly correct me if I am
wrong 8-)

Maybe I'm wrong, but if you know where the text is loaded (the final
location it is in memory), it is possible to figure out the relocations
in the sframe section.

(FWIW, What Jose wrote is correct.)

Some details which may help clear up some confusion here.  The SFrame 
sections are of type SHT_GNU_SFRAME and currently have 
SEC_ALLOC|SEC_LOAD flags set.  This means that they are allocated memory 
and loaded at application start up time.  These sections appear in a 
PT_LOAD segment in the linked binaries.

Then there is a PT_GNU_SFRAME, which is a new program header type for 
SFrame.  PT_GNU_SFRAME by itself does not trigger the loading of SFrame 
sections.  But the .sframe sections being present in the PT_LOAD segment 
does.

quoted

quoted

In the future, if we wants to compress the sframe section, it will not
even be a loadable ELF section. But the system call can tell the
kernel: "there's a sframe compressed section at this offset/size in
this file" for this text address range and then the kernel will do the
rest.

I think supporting compressed SFrame will probably require to do some
sort of relocation of the offsets in the uncompressed data, depending on
where the uncompressed data will get eventually loaded.

Assuming that all the text is at a given offset, would that be enough
to fill in the blanks?

Yes and No.  The offset at which the text is loaded is _one_ part of the 
information to "fill in the blanks".  The other part is what to do with 
that information (text_vma) or how to relocate the SFrame section itself 
a.k.a. the relocation entries.  To know the relocations, one will need 
to get access to the respective relocation section, and hence access to 
the ELF section headers.

As the text would have already been linked into memory before the
system call is made. If this is not the case, then we definitely need
the linker to load the sframe into memory before it does the system
call, and just give the kernel that address.