[PATCH] x32: Allow R_X86_64_PC64 for SFrame V3

[Indu Bhagat]

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

Thanks