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

[Josh Poimboeuf]

On Tue, Apr 08, 2025 at 07:59:48AM +0200, Jan Beulich wrote:
> 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.

Since my patches aren't merged yet, for simplicity I would try to only
support the new addressing scheme.  Either #1 or #2 would probably be ok
with me, though #1 probably has an advantage if it can be backported.

BTW, in my testing I haven't seen any .rela.sframe sections.  Any idea
how common that would be for user space binaries?  Presumably all the
binaries I've seen have a known-at-link-time distance between .text and
.sframe so they don't need relocations.

Supporting relocations might be a pain.  I'd probably have to allocate
memory, copy the .sframe section, read .rela.sframe and apply the
relocations manually.

-- 
Josh