On 2/7/2026 12:08 AM, H. Peter Anvin wrote: > On 2026-02-06 11:36, Jens Remus wrote: >> From: Josh Poimboeuf <[email protected]> >> >> Enable sframe generation in the VDSO library so kernel and user space >> can unwind through it. >> >> SFrame isn't supported for x32 or x86-32. Discard .sframe sections for >> those VDSOs. >> >> [ Jens Remus: Add support for SFrame V3. Prevent GNU_SFRAME program >> table entry to empty .sframe section. ] >> > > This will not break the x86-32 build if the assembler encounters .sframe?
I cannot follow. Assembler option --gsframe-3 is only specified in vdso64/Makefile if CONFIG_AS_SFRAME3, which affects the x86-64 and x32 VDSOs. The latter as the x32 VDSO is built from x86-64 objects converted to x86-32 objects using the X32 build step. Assembler directive ".cfi_sections .sframe" is no longer used in dwarf2.h, which affected the x86-32 VDSO if cross build on x86-64 (so that CONFIG_AS_SFRAME3=y). The reason to discard .sframe in the common VDSO linker script if !KEEP_SFRAME is to remove it from x32 VDSO (built from x86-64 objects having .sframe). It should also prevent linker errors from linkers that do not support R_X86_64_PC64 in x32 mode, such as the meanwhile fixed GNU linker: https://www.sourceware.org/bugzilla/show_bug.cgi?id=33807 > >> Notes (jremus): >> Changes in v8: >> - Discard .sframe for x32 and x86-32 VDSOs. (Josh/Indu) >> Note that the use of KEEP_SFRAME enables to define it for x86-64 >> VDSO only. Unlike CONFIG_AS_SFRAME, which may also be defined >> for x32 and x86-32 VDSO. In x32 VDSO it would result in superfluous >> .sframe (copied from the x86-64 build - could be removed in X32 >> build step). In x86-32 VDSO it would cause a bogus GNU_SFRAME >> program table entry. > > For x32, this would be a "valid" sframe, right, even if the tools currently > don't know how to consume it (and potentially never will)? If so, is there > really any reason to explicitly remove it? I am not an x86 expert. IIUC the x32 ABI uses 4-byte pointers. But GCC with option -mx32 emits DWARF that suggests that at least the return address (RA) and frame pointer (FP; rbp) are still pushed as 8-byte values on the stack, which would be relevant for SFrame: 00000000 <foo>: 0: 55 push %rbp 1: 89 e5 mov %esp,%ebp ... LOC CFA rbp ra 0000000000000000 rsp+8 u c-8 <-- suggests RA is 8-bytes on stack 0000000000000001 rsp+16 c-16 c-8 <-- suggests FP is 8-bytes on stack ... That could mean that technically the .sframe would be mostly valid. The fixed RA offset of -8 would be correct, the variable FP offset would be tracked, and the implicit SP rule SP=CFA should be correct as well. But the SFrame header would incorrectly specify AMD64 as ABI/arch ID instead of ILP32 (if I got the ELF x86-64-ABI psABI [1] correct). AFAIK SFrame does not officially support ILP32. At least GNU assembler does not: $ printf ".cfi_startproc\n.cfi_endproc\n" | as --gsframe-3 --x32 ; echo $? Assembler messages: {standard input}: Error: .sframe not supported for target 1 My take would be that it would be better to build x32 VDSO without .sframe (or discard .sframe from x32 VDSO), unless it is officially supported. @Indu: What are your thoughts as SFrame maintainer? [1]: ELF x86-64-ABI psABI, https://gitlab.com/x86-psABIs/x86-64-ABI >> /* >> * Text is well-separated from actual data: there's plenty of >> * stuff that isn't used at runtime in between. >> @@ -80,6 +87,10 @@ SECTIONS >> *(.discard) >> *(.discard.*) >> *(__bug_table) >> +#ifndef KEEP_SFRAME >> + *(.sframe) >> + *(.sframe.*) >> +#endif > > This #ifndef is actually not necessary: if we have already "consumed" the > .sframe* sections they will not be encountered here. It is necessary to remove .sframe from x86-64 objects (created by the x86-64 VDSO build) converted to x86-32 objects in the X32 build step for x32 VDSO, provided SFrame is not supported for x32. The x86-64 VDSO has .sframe, as the x86-64 VDSO linker script defines KEEP_SFRAME. The x32 VDSO has .sframe removed, as the x32 linker script does not define KEEP_SFRAME. An alternative to the #ifndef (or #if !KEEP_SFRAME) would be to remove the .sframe in the X32 build step: diff --git a/arch/x86/entry/vdso/vdso64/Makefile b/arch/x86/entry/vdso/vdso64/Makefile @@ -23,14 +24,14 @@ include $(src)/../common/Makefile.include # # Build x32 vDSO image: # 1. Compile x32 vDSO as 64bit. -# 2. Convert object files to x32. +# 2. Convert object files to x32 and remove .sframe. # 3. Build x32 VDSO image with x32 objects, which contains 64bit codes # so that it can reach 64bit address space with 64bit pointers. # # Convert 64bit object file to x32 for x32 vDSO. quiet_cmd_x32 = X32 $@ - cmd_x32 = $(OBJCOPY) -O elf32-x86-64 $< $@ + cmd_x32 = $(OBJCOPY) -O elf32-x86-64 -R .sframe $< $@ $(obj)/%-x32.o: $(obj)/%.o FORCE $(call if_changed,x32) KEEP_SFRAME (or then maybe better HAVE_SFRAME) would then still be required to only emit a program table entry, if .sframe was generated. Note that AS_SFRAME only indicates whether the assembler supports to generate .sframe. Not whether if it should actually be done. That is selected by adding the --gsframe-3 assembler option and defining KEEP_SFRAME to true, which is done in the respective VDSO Makefile and linker script. > I would prefer to have KEEP_SFRAME always defined (as true or false, and using > #if) instead of using #ifdef. I believe that also means you can do: > > #define KEEP_SFRAME IS_ENABLED(CONFIG_AS_SFRAME) > > ... instead of #ifdef. The following works and indeed looks nicer with #if KEEP_SFRAME. Will wait for further feedback on whether or not to discard .sframe in x32 VDSO before sending a v9. diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S @@ -60,7 +60,7 @@ SECTIONS *(.eh_frame.*) } :text -#ifdef KEEP_SFRAME +#if KEEP_SFRAME .sframe : { KEEP (*(.sframe)) *(.sframe.*) @@ -87,7 +87,7 @@ SECTIONS *(.discard) *(.discard.*) *(__bug_table) -#ifndef KEEP_SFRAME +#if !KEEP_SFRAME *(.sframe) *(.sframe.*) #endif @@ -116,7 +116,7 @@ PHDRS dynamic PT_DYNAMIC PF_R; note PT_NOTE PF_R; eh_frame_hdr PT_GNU_EH_FRAME PF_R; -#ifdef KEEP_SFRAME +#if KEEP_SFRAME sframe PT_GNU_SFRAME PF_R; #endif gnu_stack PT_GNU_STACK PF_RW; diff --git a/arch/x86/entry/vdso/vdso32/vdso32.lds.S b/arch/x86/entry/vdso/vdso32/vdso32.lds.S @@ -10,6 +10,7 @@ #include <asm/page.h> #define BUILD_VDSO32 +#define KEEP_SFRAME false #include "common/vdso-layout.lds.S" diff --git a/arch/x86/entry/vdso/vdso64/vdso64.lds.S b/arch/x86/entry/vdso/vdso64/vdso64.lds.S @@ -8,10 +8,7 @@ */ #define BUILD_VDSO64 - -#ifdef CONFIG_AS_SFRAME -# define KEEP_SFRAME -#endif +#define KEEP_SFRAME (CONFIG_AS_SFRAME) #include "common/vdso-layout.lds.S" diff --git a/arch/x86/entry/vdso/vdso64/vdsox32.lds.S b/arch/x86/entry/vdso/vdso64/vdsox32.lds.S @@ -8,6 +8,7 @@ */ #define BUILD_VDSOX32 +#define KEEP_SFRAME false #include "common/vdso-layout.lds.S" Thanks and regards, Jens -- Jens Remus Linux on Z Development (D3303) [email protected] / [email protected] IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294 IBM Data Privacy Statement: https://www.ibm.com/privacy/
