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

[Jan Beulich]

On 07.04.2025 02:25, Indu Bhagat wrote:
> 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/.

Thanks much for drafting this work.

> -----
> 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.

They don't look overly large and/or intrusive to me.

> 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.

With the bug you're aiming at fixing, is the present implementation actually
usable in the kernel (and possibly elsewhere)? Knowing that bug's impact is a
significant prereq to ...

> (CC Josh and Weinan for their perspective from the kernel side usecases)
> 
> What is a good choice to pick in your opinion ?

... answering this question.

Jan