[RFC,SCHEME_B 0/7] Fix relocatable links with SFrame section

[Indu Bhagat]

Hi,

This patch series in intended to help convey what it will look like to use
Scheme#B to resolve the two PRs related to relocatable links involving SFrame
sections:

PR ld/32666 - Incorrect .rela.sframe when using ld -r
PR libsframe/32589 - function start address is zero in SFrame section dump

A previously posted patch series (with a similar title) used the approach of
using Scheme#A in GAS/ld
https://inbox.sourceware.org/binutils/20250331185205.3755087-1-indu.bhagat@oracle.com/.

-----
In SFrame V2, SFrame function descriptor entry is a 32-bit signed integer
(sfde_func_start_address) which is meant to somehow denote the start PC of the
function.

(Scheme #A) According to the current specification, it intends to hold the
offset of the start PC of the function from the _start_of_the_SFrame_section_.
    
(Scheme #B) The 'sfde_func_start_address' field may instead be made to hold the
offset of the start PC of the function from the relocation place
(_start_of_SFrame_FDE_).

Patch 1 updates the linker to emit sfde_func_start_address in the in-memory
buffer (containing SFrame section) as the distance from the FDE to the start PC
(i.e. Scheme#B).

Patch 2 and 4 are the same as posted for the series using Scheme#A earlier.

Patch 5 shows the impact of using scheme#B on libsframe.  Adjustments similar
to those done in sframe_find_fre () function can be expected from SFrame based
stack tracers.

Rest of the patches are self-explanatory.

What is missing from this series is the decision on the way we approach the
matter, if we pick to resolve the issue  by fixing the spec (i.e. adopting
Scheme#B):

 #1. Introduce a new flag (say SFRAME_F_FDE_FUNC_START_ADDR_PCREL) with a value
     of 0x4 (0x1 << 2), or
 #2. Bump the version to SFrame version 3.

When chosing Scheme#A (patches sent earlier [1]), the above choice/complication
does not manifest because its the adoption of Scheme#B that necessitates a spec
change.  In that sense, this spec change is such that in order to fix ET_REL,
both ET_DYN, ET_EXEC binaries are affected.

SFrame version 2 (current version) was first released in GNU Binutils 2.41;
SFrame version 2 uses Scheme#A.  Picking #1 above helps make the bugfix
backportable "in theory".  But I wonder if adopting Scheme#B truly is something
that can be backported at all.  A user's toolchain once upgraded to a bugfixed
version (if using Scheme#B) does imply recompilation of their user application
of interest (which wants to use SFrame relocatable links), and availability of
a Scheme#B-aware stack tracer.  It seems to me that scheme#B based solution is
tricky because backporting it is desirable but somewhat user-unfriendly.

Picking #2 implies that we do not fix these bugs in previous releases.  The
bugfix will only be available in SFrame verison 3; this is not favorable for
the kernel side usecases I think.

(CC Josh and Weinan for their perspective from the kernel side usecases)

What is a good choice to pick in your opinion ?

[1] Fix SFrame relocatable links using Scheme#A 
   https://inbox.sourceware.org/binutils/20250331185205.3755087-1-indu.bhagat@oracle.com/

Thanks,

Indu Bhagat (7):
  ld: sframe: emit function start addr as offset from FDE
  objdump, readelf: sframe: apply relocations before textual dump
  libsframe: process FDE function start addr before dumping
  ld: bfd: sframe: fix incorrect r_offset in RELA entries
  libsframe: SFrame FDE function start addr is an offset from FDE
  sframe: doc: use new encoding for sfde_func_start_addr
  NEWS: sframe: mention new semantics for SFrame FDE function start addr

 bfd/elf-bfd.h                                 | 11 +++
 bfd/elf-sframe.c                              | 70 ++++++++++++++++++-
 bfd/elf.c                                     |  3 +
 bfd/elflink.c                                 |  6 +-
 binutils/NEWS                                 |  4 ++
 binutils/dwarf.c                              | 35 ++++++++++
 binutils/dwarf.h                              |  1 +
 binutils/objdump.c                            | 59 ++++++----------
 binutils/readelf.c                            | 50 +++----------
 .../cfi-sframe-aarch64-pac-ab-key-1.d         |  8 +--
 ld/testsuite/ld-x86-64/sframe-reloc-1.d       | 34 +++++++++
 ld/testsuite/ld-x86-64/x86-64.exp             |  1 +
 libsframe/doc/sframe-spec.texi                |  2 +-
 libsframe/sframe-dump.c                       |  4 +-
 libsframe/sframe.c                            | 68 ++++++++++++++----
 15 files changed, 256 insertions(+), 100 deletions(-)
 create mode 100644 ld/testsuite/ld-x86-64/sframe-reloc-1.d

-- 
2.43.0