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

[Jan Beulich]

On 08.04.2025 03:07, Indu Bhagat wrote:
> On 4/7/25 8:26 AM, Jan Beulich wrote:
>> 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 ...
>>
> 
> On the kernel side, work is underway to use present implementation of 
> SFrame in
> Binutils in two ways:
> 
> [#1] Userspace stack tracing in the kernel:
> https://lore.kernel.org/linux-toolchains/cover.1737511963.git.jpoimboe@kernel.org/
> 
> [#2] Kernelspace stack tracing to enable livepatching (arm64):
> https://lore.kernel.org/linux-toolchains/20250127213310.2496133-1-wnliu@google.com/
> 
> Then there is the glibc stacktracer effort ([#3]) using SFrame, RFC patches
> were recently posted.
> https://inbox.sourceware.org/libc-alpha/20250318130333.18829-1-claudiu.zissulescu-ianculescu@oracle.com/
> 
> It is the #2 that makes use of relocatable links (for kernel modules) 
> that is
> directly affected by these bugs.  On the userspace side in general: although
> not directly impacting the efforts in #1 or #3 right now (as we can 
> adapt the
> stack tracers currently in progress), there may be applications of 
> relocatable
> links in user packages..

Which would then also be broken either way. I'm inclined to think ...

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

... that #1 here is the best approach, as long as handling both cases (flag set
and flag unset) doesn't result in too ugly code. Relocatable links would be
properly supported only for the "flag set" case.

Let's see what others think.

Jan