On 7/23/25 8:09 AM, Mathieu Desnoyers wrote:
On 2025-07-22 17:13, Steven Rostedt wrote:
On Tue, 22 Jul 2025 14:04:37 -0700
Indu Bhagat <indu.bhagat@xxxxxxxxxx> wrote:
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.
You mean to find where in the sframe section itself that needs to be
update?
OK, that makes sense. So sframes does need to still be in an ELF file for
its own relocations and such.
It will be interesting on how to do compression and on-demand page
loading.
There would need to be a table as well that will denote where in the
decompressed pages that relocations need to be performed.
If we can find a way to express all sframe "pointers" as offsets from a
text_vma base, then there is no need for relocations. This would
minimize complexity.
(So we got into the topic of relocation in the context of compressing
SFrame sections, the details of which are not chalked out yet. As I
mentioned SHF_ALLOC|SHF_COMPRESSED usecase needs to be discussed
further. But stating the following in case there has been a
misunderstanding.)
The SFrame FDE func start addr field is indeed an offset from the field
itself to the start PC of the function in the text section. So in
relocatable files (object files, or ld -r i.e. ET_REL), we see the
relocations.
These relocations can be resolved at link time by the linker. So for
shared libraries and executables (ET_DYN, ET_EXEC), once the SFrame
section in placed in the PT_LOAD segment, there are no relocations for
readers/consumers. These relocations remain for relocatable objects.
A consumer of relocatable object, e.g., in case of kernel modules, will
need to take care of the relocations when adding the module.
