linux-toolchains.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Start PC of function in SFrame FDE
@ 2023-05-16 22:43 Indu Bhagat
  0 siblings, 0 replies; only message in thread
From: Indu Bhagat @ 2023-05-16 22:43 UTC (permalink / raw)
  To: Steven Rostedt, linux-toolchains

Hi,

During one of our discussions at LSF/MM/BPF, there was a confusion 
around what value is stored in the "Start PC" in the SFrame Function 
Descriptor Entry (FDE).

Short answer:
The start PC of function, as encoded in the SFrame FDE is a 4-byte 
non-zero signed value representing the offset to the start instruction 
of the function, from the start of the SFrame section.

Longer version:

(Excerpts below use x86_64 artifacts)

For a toy program with 4 functions, there are 4 FDEs (See below, 1 reloc 
per FDE). Each reloc is for the respective function symbol in the object 
file.

$ readelf --relocs deep_hello_sframe.o

Relocation section '.rela.sframe' at offset 0x4e0 contains 4 entries:
   Offset          Info           Type           Sym. Value    Sym. Name 
+ Addend
00000000001c  000200000002 R_X86_64_PC32     0000000000000000 .text + 0
00000000002d  000200000002 R_X86_64_PC32     0000000000000000 .text + 19
00000000003e  000200000002 R_X86_64_PC32     0000000000000000 .text + 49
00000000004f  000200000002 R_X86_64_PC32     0000000000000000 .text + 79

As you see below, the "pointed to" entity is the function start 
location. These R_X86_64_PC32 relocations in SFrame FDEs are resolved at 
link-time.

Symbol table '.symtab' contains XX entries:
    Num:    Value          Size Type    Bind   Vis      Ndx Name
      ...
      4: 0000000000000000    25 FUNC    GLOBAL DEFAULT    1 baz
      ...
      6: 0000000000000019    48 FUNC    GLOBAL DEFAULT    1 bar
      7: 0000000000000049    48 FUNC    GLOBAL DEFAULT    1 foo
      8: 0000000000000079    51 FUNC    GLOBAL DEFAULT    1 main
      ...

Now when linking this object, first, the linker resolves these the 
standard R_X86_64_PC32 relocations generically as per the ABI specification:

Calculation = S + A - P.

In the above,
S = value of the .text section symbol
A = Addend, value will be as shown in the "Sym. Name + Addend" column
P = Represents the place (section offset or address) of the storage unit 
being relocated

Now the P here will be value of the .sframe section symbol + Offset as 
shown in the "Offset" column, i.e., sframe_vma + Offset

So the value in the first step is:
(1) Value = S + A - (sframe_vma + Offset)

Next, when merging the .sframe section, the linker does an additional 
step of making this value relative to the start of the SFrame section by 
doing:
(2) Value += Offset

So, at the end of the above two steps, the value is:
(3) Value = S + A - sframe_vma

This (3) is the value stored in "Start PC of function" in the SFrame 
FDE. I will clarify the SPEC to reflect that the start PC of the 
function, as encoded in the FDE is a 4-byte non-zero signed value 
representing the offset of the start PC relative to the start of the 
SFrame section.

This means that given a PC, the stack tracer will need to lookup the 
SFrame FDE with lookup_address = PC - sframe_vma.

Hope this helps.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2023-05-16 22:43 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-05-16 22:43 Start PC of function in SFrame FDE 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 NNTP newsgroup(s).