[PATCH] x32: Allow R_X86_64_PC64 for SFrame V3

[H.J. Lu]

On Fri, Jan 23, 2026 at 2:15 AM Indu Bhagat <indu.bhagat@oracle.com> wrote:
>
> On 1/19/26 12:16 PM, Indu Bhagat wrote:
> > On 1/18/26 6:19 PM, H.J. Lu wrote:
> >> SFrame V3 generates R_X86_64_PC64 relocation, instead of R_X86_64_PC32,
> >> in .sframe section for x86-64.  Although x32 doesn't support SFrame,
> >> .sframe section can be found in x32 object converted from x86-64 object
> >> with objcopy, which only changes the ELF file class from ELFCLASS64 to
> >> ELFCLASS32 with all section contents unchanged.
> >>
> >> Update elf_x86_64_scan_relocs to allow R_X86_64_PC64 for x32 so that
> >> x32 object file with .sframe section can be used as x32 linker input.
> >>
> >> bfd/
> >>
> >> PR ld/33807
> >> * elf64-x86-64.c (elf_x86_64_scan_relocs): Allow R_X86_64_PC64
> >> for x32.
> >>
> >> ld/
> >>
> >> PR ld/33807
> >> * testsuite/ld-x86-64/sframe.rd: New file.
> >> * testsuite/ld-x86-64/sframe.s: Likewise.
> >> * testsuite/ld-x86-64/x86-64.exp: Run PR ld/33807 tests.
> >>
> >>
> >
> > Thanks HJ for the patch.
> >
> > (Adding Mathieu, Steve and Josh.)
> >
> > For context, we see the issue with kernel builds with SFrame V3 enabled
> > (https://sourceware.org/bugzilla/show_bug.cgi?id=33807).  SFrame V3
> > sections use 64-bit start pc offset by  default, and hence see the
> > R_X86_64_PC64 relas.
> >
> > The proposed patch fixes ld to not complain about R_X86_64_PC64 in x32
> > objects.  IOW, with this patch, users will have a way to create .sframe
> > sections in x32 objects.  FWIW, GAS does not generate .sframe for x32.
> > But users could have used objcopy and then ld even in previous GNU
> > Binutils (which supported SFrame V2) to create SFrame V2 sections (which
> > had R_X86_64_PC32) for x32 binaries..
> >
> > Mathieu, I am reminded of a discussion with you sometime ago regarding a
> > concern that if there is a way to create .sframe sections for x32
> > binaries, it may expose some vulnerable code paths in the Linux kernel
> > stacktracer/SFrame related bits.  Can you remind what the issue was/is ?
> >
> > In general, I am wondering what is the right thing to do here:
> >    - restrict the kernel's linker scripts to discard .sframe for x32
> > objects or,
> >    - should 'objcopy -O elf32-x86-64' pick one of the behaviors:
> >      + silently skip .sframe/.rela.sframe, or
> >      + alert the user with non-fatal error and not
> > copy .sframe/.rela.sframe
> >
>
> In the SFrame meeting earlier this week, we talked a bit about this PR.
>
> As for the vulnerable code paths related x32, perhaps I had been
> misremembering something.  Either way, it is acceptable to expect the
> associated kernel script vdsox32.lds be adapted to discard SFrame
> section for x32 binary as necessary.
>
> Summary: we can move forward with HJ's patch.
>

I checked in my fix.

-- 
H.J.