Re: [PATCH v8 6/6] x86/vdso: Enable sframe generation in VDSO

On 2/7/2026 12:08 AM, H. Peter Anvin wrote:

On 2026-02-06 11:36, Jens Remus wrote:

quoted

From: Josh Poimboeuf <jpoimboe@kernel.org>

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

quoted

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

quoted

 	/*
 	 * 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)
jremus@de.ibm.com / jremus@linux.ibm.com

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/