[PATCH v8 0/6] x86/vdso: VDSO updates and fixes for sframes

[PATCH v8 0/6] x86/vdso: VDSO updates and fixes for sframes

[Jens Remus]

This enables generation of SFrame V3 stack trace information for VDSO on
x86-64.  It's a continuation of Josh's and Steve's work:

   https://lore.kernel.org/all/cover.1737511963.git.jpoimboe@kernel.org/
   https://lore.kernel.org/all/20250425023750.669174660@goodmis.org/

This series focuses only on the VDSO code. They are helpful fixes
and updates that doesn't rely on sframes (although the last patch
is sframe related).

This series applies on top of tip:x86/entry:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  x86/entry

Like the unwind user sframe series [1] it depends on the upcoming
binutils 2.46 release to be used to build the VDSO with SFrame V3
stack trace information (using the assembler option --gsframe-3).

[1]: [PATCH v13 00/18] unwind_deferred: Implement sframe handling,
    https://lore.kernel.org/all/20260127150554.2760964-1-jremus@linux.ibm.com/

Changes in v8 (see individual patch notes):
- Discard .sframe for x32 and x86-32 VDSOs. (Josh/Indu)
- Define CFI_SIGNAL_FRAME for !BUILD_VDSO.
- Drop .cfi_sections .sframe in dwarf2.h in favor of the explicitly
  specified more specific assembler option --gsframe-3.
- Incorporate missing changes and review feedback from Steven's v6
  (I erroneously based my v6 on Steven's v5):
  - Reword patch 3 commit subject to Steven's v6 one.
  - Remove SYM_F_ALIGN in __vdso_sgx_enter_enclave(). (Josh)

Changes in v7 (see individual patch notes):
- Rebase on H. Peter Anvin's vDSO changes on tip:x86/entry. (Peter)
- Simplify adding assembler option -Wa,--gsframe-3.  Add for vdso64
  only.
- Align to .eh_frame and mark .sframe as KEEP in vDSO linker script.
  Note that GNU linker 2.46 will mark .sframe as KEEP in its default
  linker script as well.

Changes in v6:
- SFrame V3 support (SFrame V2 is not supported).
- Prevent GNU_SFRAME program table entry to empty .sframe section.
- Integrate v5 review feedback. (Josh)


I verified as follows on x86-64 using a binutils 2.46 pre-release build
that only the x86-64 VDSO has an .sframe section and GNU_SFRAME program
table entry:

$ make defconfig
*** Default configuration is based on 'x86_64_defconfig'
$ make arch/x86/entry/vdso/
  OBJCOPY arch/x86/entry/vdso/vdso64/vdso64.so
  VDSO2C  arch/x86/entry/vdso/vdso64/vdso64-image.c
  VDSO    arch/x86/entry/vdso/vdso32/vdso32.so.dbg
  OBJCOPY arch/x86/entry/vdso/vdso32/vdso32.so
$ readelf -WSl arch/x86/entry/vdso/vdso*/vdso*.so | egrep "File:|GNU_SFRAME"
File: arch/x86/entry/vdso/vdso32/vdso32.so
File: arch/x86/entry/vdso/vdso64/vdso64.so
  [13] .sframe           GNU_SFRAME      00000000000007e0 0007e0 00012b 00   A  0   0  8
  GNU_SFRAME     0x0007e0 0x00000000000007e0 0x00000000000007e0 0x00012b 0x00012b R   0x8

$ make defconfig
*** Default configuration is based on 'x86_64_defconfig'
$ ./scripts/config --enable X86_X32_ABI
$ make arch/x86/entry/vdso/
  VDSO    arch/x86/entry/vdso/vdso64/vdso64.so.dbg
  OBJCOPY arch/x86/entry/vdso/vdso64/vdso64.so
  VDSO    arch/x86/entry/vdso/vdso64/vdsox32.so.dbg
  OBJCOPY arch/x86/entry/vdso/vdso64/vdsox32.so
  VDSO    arch/x86/entry/vdso/vdso32/vdso32.so.dbg
  OBJCOPY arch/x86/entry/vdso/vdso32/vdso32.so
$ readelf -WSl arch/x86/entry/vdso/vdso*/vdso*.so | egrep "File:|GNU_SFRAME"
File: arch/x86/entry/vdso/vdso32/vdso32.so
File: arch/x86/entry/vdso/vdso64/vdso64.so
  [13] .sframe           GNU_SFRAME      00000000000007e0 0007e0 00012b 00   A  0   0  8
  GNU_SFRAME     0x0007e0 0x00000000000007e0 0x00000000000007e0 0x00012b 0x00012b R   0x8
File: arch/x86/entry/vdso/vdso64/vdsox32.so

$ make ARCH=i386 defconfig
*** Default configuration is based on 'i386_defconfig'
$ make ARCH=i386 arch/x86/entry/vdso/
  VDSO    arch/x86/entry/vdso/vdso32/vdso32.so.dbg
  OBJCOPY arch/x86/entry/vdso/vdso32/vdso32.so
$ readelf -WSl arch/x86/entry/vdso/vdso*/*.so | egrep "File:|GNU_SFRAME"

Regards,
Jens


Josh Poimboeuf (6):
  x86/vdso: Fix DWARF generation for getrandom()
  x86/asm: Avoid emitting DWARF CFI for non-VDSO
  x86/asm: Use CFI_* macros in SYM_FUNC_* macros so they can be added to
    VDSO
  x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall()
  x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave()
  x86/vdso: Enable sframe generation in VDSO

 arch/Kconfig                                  |  7 +++
 arch/x86/entry/vdso/common/vdso-layout.lds.S  | 17 +++++-
 arch/x86/entry/vdso/vdso32/system_call.S      | 10 +---
 arch/x86/entry/vdso/vdso64/Makefile           |  1 +
 arch/x86/entry/vdso/vdso64/vdso64.lds.S       |  4 ++
 .../x86/entry/vdso/vdso64/vgetrandom-chacha.S |  3 +-
 arch/x86/entry/vdso/vdso64/vsgx.S             | 18 +++----
 arch/x86/include/asm/dwarf2.h                 | 52 +++++++++++++------
 arch/x86/include/asm/linkage.h                | 33 +++++++++---
 arch/x86/include/asm/vdso.h                   |  1 -
 10 files changed, 100 insertions(+), 46 deletions(-)

-- 
2.51.0

[PATCH v8 1/6] x86/vdso: Fix DWARF generation for getrandom()

[Jens Remus]

From: Josh Poimboeuf <jpoimboe@kernel.org>

Add CFI annotations to the VDSO implementation of getrandom() so it will
have valid DWARF unwinding metadata.

Fixes: 33385150ac45 ("x86: vdso: Wire up getrandom() vDSO implementation")
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
 arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
index bcba5639b8ee..cc82da9216fb 100644
--- a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
+++ b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
@@ -4,7 +4,7 @@
  */
 
 #include <linux/linkage.h>
-#include <asm/frame.h>
+#include <asm/dwarf2.h>
 
 .section	.rodata, "a"
 .align 16
@@ -22,7 +22,7 @@ CONSTANTS:	.octa 0x6b20657479622d323320646e61707865
  *	rcx: number of 64-byte blocks to write to output
  */
 SYM_FUNC_START(__arch_chacha20_blocks_nostack)
-
+	CFI_STARTPROC
 .set	output,		%rdi
 .set	key,		%rsi
 .set	counter,	%rdx
@@ -175,4 +175,5 @@ SYM_FUNC_START(__arch_chacha20_blocks_nostack)
 	pxor		temp,temp
 
 	ret
+	CFI_ENDPROC
 SYM_FUNC_END(__arch_chacha20_blocks_nostack)
-- 
2.51.0

[PATCH v8 2/6] x86/asm: Avoid emitting DWARF CFI for non-VDSO

[Jens Remus]

From: Josh Poimboeuf <jpoimboe@kernel.org>

It was decided years ago that .cfi_* annotations aren't maintainable in
the kernel.  They were replaced by objtool unwind hints.  For the kernel
proper, ensure the CFI_* macros don't do anything.

On the other hand the VDSO library *does* use them, so user space can
unwind through it.

Make sure these macros only work for VDSO.  They aren't actually being
used outside of VDSO anyway, so there's no functional change.

[ Jens Remus: Define CFI_SIGNAL_FRAME for !BUILD_VDSO. ]

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---

Notes (jremus):
    Changes in v8:
    - Define CFI_SIGNAL_FRAME for !BUILD_VDSO (new on tip:x86/entry).

 arch/x86/include/asm/dwarf2.h | 52 ++++++++++++++++++++++++-----------
 1 file changed, 36 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/dwarf2.h b/arch/x86/include/asm/dwarf2.h
index 09c9684d3ad6..13e2e64ef265 100644
--- a/arch/x86/include/asm/dwarf2.h
+++ b/arch/x86/include/asm/dwarf2.h
@@ -6,6 +6,15 @@
 #warning "asm/dwarf2.h should be only included in pure assembly files"
 #endif
 
+#ifdef BUILD_VDSO
+
+	/*
+	 * For the vDSO, emit both runtime unwind information and debug
+	 * symbols for the .dbg file.
+	 */
+
+	.cfi_sections .eh_frame, .debug_frame
+
 #define CFI_STARTPROC		.cfi_startproc
 #define CFI_ENDPROC		.cfi_endproc
 #define CFI_DEF_CFA		.cfi_def_cfa
@@ -22,21 +31,32 @@
 #define CFI_ESCAPE		.cfi_escape
 #define CFI_SIGNAL_FRAME	.cfi_signal_frame
 
-#ifndef BUILD_VDSO
-	/*
-	 * Emit CFI data in .debug_frame sections, not .eh_frame sections.
-	 * The latter we currently just discard since we don't do DWARF
-	 * unwinding at runtime.  So only the offline DWARF information is
-	 * useful to anyone.  Note we should not use this directive if we
-	 * ever decide to enable DWARF unwinding at runtime.
-	 */
-	.cfi_sections .debug_frame
-#else
-	 /*
-	  * For the vDSO, emit both runtime unwind information and debug
-	  * symbols for the .dbg file.
-	  */
-	.cfi_sections .eh_frame, .debug_frame
-#endif
+#else /* !BUILD_VDSO */
+
+/*
+ * On x86, these macros aren't used outside VDSO.  As well they shouldn't be:
+ * they're fragile and very difficult to maintain.
+ */
+
+.macro nocfi args:vararg
+.endm
+
+#define CFI_STARTPROC		nocfi
+#define CFI_ENDPROC		nocfi
+#define CFI_DEF_CFA		nocfi
+#define CFI_DEF_CFA_REGISTER	nocfi
+#define CFI_DEF_CFA_OFFSET	nocfi
+#define CFI_ADJUST_CFA_OFFSET	nocfi
+#define CFI_OFFSET		nocfi
+#define CFI_REL_OFFSET		nocfi
+#define CFI_REGISTER		nocfi
+#define CFI_RESTORE		nocfi
+#define CFI_REMEMBER_STATE	nocfi
+#define CFI_RESTORE_STATE	nocfi
+#define CFI_UNDEFINED		nocfi
+#define CFI_ESCAPE		nocfi
+#define CFI_SIGNAL_FRAME	nocfi
+
+#endif /* !BUILD_VDSO */
 
 #endif /* _ASM_X86_DWARF2_H */
-- 
2.51.0

[PATCH v8 3/6] x86/asm: Use CFI_* macros in SYM_FUNC_* macros so they can be added to VDSO

[Jens Remus]

From: Josh Poimboeuf <jpoimboe@kernel.org>

Add CFI_STARTPROC and CFI_ENDPROC annotations to the SYM_FUNC_* macros
so the VDSO asm functions don't need to add them manually.  Note this
only affects VDSO, the CFI_* macros are empty for the kernel proper.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---

Notes (jremus):
    Changes in v8:
    - Reword commit subject to Steven's v6 one:
      https://lore.kernel.org/all/20250425024022.652143069@goodmis.org/
    - Drop my changelog from the commit message, as the patch is now
      identical to Steven's v6.

 arch/x86/entry/vdso/common/vdso-layout.lds.S  |  2 +-
 .../x86/entry/vdso/vdso64/vgetrandom-chacha.S |  2 --
 arch/x86/entry/vdso/vdso64/vsgx.S             |  4 ---
 arch/x86/include/asm/linkage.h                | 33 +++++++++++++++----
 arch/x86/include/asm/vdso.h                   |  1 -
 5 files changed, 28 insertions(+), 14 deletions(-)

diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S
index a1e30be3e83d..856b8b9d278c 100644
--- a/arch/x86/entry/vdso/common/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/common/vdso-layout.lds.S
@@ -1,5 +1,5 @@
 /* SPDX-License-Identifier: GPL-2.0 */
-#include <asm/vdso.h>
+#include <asm/page_types.h>
 #include <asm/vdso/vsyscall.h>
 #include <vdso/datapage.h>
 
diff --git a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
index cc82da9216fb..a33212594731 100644
--- a/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
+++ b/arch/x86/entry/vdso/vdso64/vgetrandom-chacha.S
@@ -22,7 +22,6 @@ CONSTANTS:	.octa 0x6b20657479622d323320646e61707865
  *	rcx: number of 64-byte blocks to write to output
  */
 SYM_FUNC_START(__arch_chacha20_blocks_nostack)
-	CFI_STARTPROC
 .set	output,		%rdi
 .set	key,		%rsi
 .set	counter,	%rdx
@@ -175,5 +174,4 @@ SYM_FUNC_START(__arch_chacha20_blocks_nostack)
 	pxor		temp,temp
 
 	ret
-	CFI_ENDPROC
 SYM_FUNC_END(__arch_chacha20_blocks_nostack)
diff --git a/arch/x86/entry/vdso/vdso64/vsgx.S b/arch/x86/entry/vdso/vdso64/vsgx.S
index 37a3d4c02366..c0342238c976 100644
--- a/arch/x86/entry/vdso/vdso64/vsgx.S
+++ b/arch/x86/entry/vdso/vdso64/vsgx.S
@@ -24,8 +24,6 @@
 .section .text, "ax"
 
 SYM_FUNC_START(__vdso_sgx_enter_enclave)
-	/* Prolog */
-	.cfi_startproc
 	push	%rbp
 	.cfi_adjust_cfa_offset	8
 	.cfi_rel_offset		%rbp, 0
@@ -143,8 +141,6 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)
 	jle	.Lout
 	jmp	.Lenter_enclave
 
-	.cfi_endproc
-
 _ASM_VDSO_EXTABLE_HANDLE(.Lenclu_eenter_eresume, .Lhandle_exception)
 
 SYM_FUNC_END(__vdso_sgx_enter_enclave)
diff --git a/arch/x86/include/asm/linkage.h b/arch/x86/include/asm/linkage.h
index 9d38ae744a2e..9d7f90c57451 100644
--- a/arch/x86/include/asm/linkage.h
+++ b/arch/x86/include/asm/linkage.h
@@ -40,6 +40,10 @@
 
 #ifdef __ASSEMBLER__
 
+#ifndef LINKER_SCRIPT
+#include <asm/dwarf2.h>
+#endif
+
 #if defined(CONFIG_MITIGATION_RETHUNK) && !defined(__DISABLE_EXPORTS) && !defined(BUILD_VDSO)
 #define RET	jmp __x86_return_thunk
 #else /* CONFIG_MITIGATION_RETPOLINE */
@@ -112,34 +116,51 @@
 # define SYM_FUNC_ALIAS_MEMFUNC	SYM_FUNC_ALIAS
 #endif
 
+#define __SYM_FUNC_START				\
+	CFI_STARTPROC ASM_NL
+
+#define __SYM_FUNC_END					\
+	CFI_ENDPROC ASM_NL
+
 /* SYM_TYPED_FUNC_START -- use for indirectly called globals, w/ CFI type */
 #define SYM_TYPED_FUNC_START(name)				\
 	SYM_TYPED_START(name, SYM_L_GLOBAL, SYM_F_ALIGN)	\
+	__SYM_FUNC_START					\
 	ENDBR
 
 /* SYM_FUNC_START -- use for global functions */
 #define SYM_FUNC_START(name)				\
-	SYM_START(name, SYM_L_GLOBAL, SYM_F_ALIGN)
+	SYM_START(name, SYM_L_GLOBAL, SYM_F_ALIGN)	\
+	__SYM_FUNC_START
 
 /* SYM_FUNC_START_NOALIGN -- use for global functions, w/o alignment */
 #define SYM_FUNC_START_NOALIGN(name)			\
-	SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE)
+	SYM_START(name, SYM_L_GLOBAL, SYM_A_NONE)	\
+	__SYM_FUNC_START
 
 /* SYM_FUNC_START_LOCAL -- use for local functions */
 #define SYM_FUNC_START_LOCAL(name)			\
-	SYM_START(name, SYM_L_LOCAL, SYM_F_ALIGN)
+	SYM_START(name, SYM_L_LOCAL, SYM_F_ALIGN)	\
+	__SYM_FUNC_START
 
 /* SYM_FUNC_START_LOCAL_NOALIGN -- use for local functions, w/o alignment */
 #define SYM_FUNC_START_LOCAL_NOALIGN(name)		\
-	SYM_START(name, SYM_L_LOCAL, SYM_A_NONE)
+	SYM_START(name, SYM_L_LOCAL, SYM_A_NONE)	\
+	__SYM_FUNC_START
 
 /* SYM_FUNC_START_WEAK -- use for weak functions */
 #define SYM_FUNC_START_WEAK(name)			\
-	SYM_START(name, SYM_L_WEAK, SYM_F_ALIGN)
+	SYM_START(name, SYM_L_WEAK, SYM_F_ALIGN)	\
+	__SYM_FUNC_START
 
 /* SYM_FUNC_START_WEAK_NOALIGN -- use for weak functions, w/o alignment */
 #define SYM_FUNC_START_WEAK_NOALIGN(name)		\
-	SYM_START(name, SYM_L_WEAK, SYM_A_NONE)
+	SYM_START(name, SYM_L_WEAK, SYM_A_NONE)		\
+	__SYM_FUNC_START
+
+#define SYM_FUNC_END(name)				\
+	__SYM_FUNC_END					\
+	SYM_END(name, SYM_T_FUNC)
 
 /*
  * Expose 'sym' to the startup code in arch/x86/boot/startup/, by emitting an
diff --git a/arch/x86/include/asm/vdso.h b/arch/x86/include/asm/vdso.h
index e8afbe9faa5b..498ac423741c 100644
--- a/arch/x86/include/asm/vdso.h
+++ b/arch/x86/include/asm/vdso.h
@@ -2,7 +2,6 @@
 #ifndef _ASM_X86_VDSO_H
 #define _ASM_X86_VDSO_H
 
-#include <asm/page_types.h>
 #include <linux/linkage.h>
 #include <linux/init.h>
 
-- 
2.51.0

[PATCH v8 4/6] x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall()

[Jens Remus]

From: Josh Poimboeuf <jpoimboe@kernel.org>

Use SYM_FUNC_{START,END} instead of all the boilerplate.  No functional
change.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---
 arch/x86/entry/vdso/vdso32/system_call.S | 10 ++--------
 1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/arch/x86/entry/vdso/vdso32/system_call.S b/arch/x86/entry/vdso/vdso32/system_call.S
index 9157cf9c5749..a90f4f7de396 100644
--- a/arch/x86/entry/vdso/vdso32/system_call.S
+++ b/arch/x86/entry/vdso/vdso32/system_call.S
@@ -9,11 +9,7 @@
 #include <asm/alternative.h>
 
 	.text
-	.globl __kernel_vsyscall
-	.type __kernel_vsyscall,@function
-	ALIGN
-__kernel_vsyscall:
-	CFI_STARTPROC
+SYM_FUNC_START(__kernel_vsyscall)
 
 	/*
 	 * If using int $0x80, there is no reason to muck about with the
@@ -85,7 +81,5 @@ SYM_INNER_LABEL(int80_landing_pad, SYM_L_GLOBAL)
 	CFI_RESTORE		ecx
 	CFI_ADJUST_CFA_OFFSET	-4
 	RET
-	CFI_ENDPROC
-
-	.size __kernel_vsyscall,.-__kernel_vsyscall
+SYM_FUNC_END(__kernel_vsyscall)
 	.previous
-- 
2.51.0

[PATCH v8 5/6] x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave()

[Jens Remus]

From: Josh Poimboeuf <jpoimboe@kernel.org>

Use the CFI macros instead of the raw .cfi_* directives to be consistent
with the rest of the VDSO asm.  It's also easier on the eyes.

No functional changes.

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---

Notes (jremus):
    Changes in v8:
    - Remove SYM_F_ALIGN. (Josh)
      https://lore.kernel.org/all/amh7fzsjx4p5nowy3b3j6blkty5ojqf7jawtlslexwzdbxrhc3@zersgacmcnai/

 arch/x86/entry/vdso/vdso64/vsgx.S | 14 ++++++--------
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/arch/x86/entry/vdso/vdso64/vsgx.S b/arch/x86/entry/vdso/vdso64/vsgx.S
index c0342238c976..76efbeb1e287 100644
--- a/arch/x86/entry/vdso/vdso64/vsgx.S
+++ b/arch/x86/entry/vdso/vdso64/vsgx.S
@@ -25,12 +25,12 @@
 
 SYM_FUNC_START(__vdso_sgx_enter_enclave)
 	push	%rbp
-	.cfi_adjust_cfa_offset	8
-	.cfi_rel_offset		%rbp, 0
+	CFI_ADJUST_CFA_OFFSET	8
+	CFI_REL_OFFSET		%rbp, 0
 	mov	%rsp, %rbp
-	.cfi_def_cfa_register	%rbp
+	CFI_DEF_CFA_REGISTER	%rbp
 	push	%rbx
-	.cfi_rel_offset		%rbx, -8
+	CFI_REL_OFFSET		%rbx, -8
 
 	mov	%ecx, %eax
 .Lenter_enclave:
@@ -77,13 +77,11 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave)
 .Lout:
 	pop	%rbx
 	leave
-	.cfi_def_cfa		%rsp, 8
+	CFI_DEF_CFA		%rsp, 8
 	RET
 
-	/* The out-of-line code runs with the pre-leave stack frame. */
-	.cfi_def_cfa		%rbp, 16
-
 .Linvalid_input:
+	CFI_DEF_CFA		%rbp, 16
 	mov	$(-EINVAL), %eax
 	jmp	.Lout
 
-- 
2.51.0

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

[Jens Remus]

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. ]

Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
---

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.
    - Reword commit message (append Josh's private fix).
    - Drop .cfi_sections .sframe in dwarf2.h in favor of the explicitly
      specified more specific assembler option --gsframe-3.  With this
      it is not necessary to undefine CONFIG_AS_SFRAME in
      fake_32bit_build.h.

 arch/Kconfig                                 |  7 +++++++
 arch/x86/entry/vdso/common/vdso-layout.lds.S | 15 +++++++++++++++
 arch/x86/entry/vdso/vdso64/Makefile          |  1 +
 arch/x86/entry/vdso/vdso64/vdso64.lds.S      |  4 ++++
 4 files changed, 27 insertions(+)

diff --git a/arch/Kconfig b/arch/Kconfig
index 31220f512b16..8170e492a44c 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -479,6 +479,13 @@ config HAVE_HARDLOCKUP_DETECTOR_ARCH
 	  It uses the same command line parameters, and sysctl interface,
 	  as the generic hardlockup detectors.
 
+config AS_SFRAME
+	bool
+
+config AS_SFRAME3
+	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)
+	select AS_SFRAME
+
 config UNWIND_USER
 	bool
 
diff --git a/arch/x86/entry/vdso/common/vdso-layout.lds.S b/arch/x86/entry/vdso/common/vdso-layout.lds.S
index 856b8b9d278c..47e6a6a0560a 100644
--- a/arch/x86/entry/vdso/common/vdso-layout.lds.S
+++ b/arch/x86/entry/vdso/common/vdso-layout.lds.S
@@ -60,6 +60,13 @@ SECTIONS
 		*(.eh_frame.*)
 	}					:text
 
+#ifdef KEEP_SFRAME
+	.sframe		: {
+		KEEP (*(.sframe))
+		*(.sframe.*)
+	}					:text	:sframe
+#endif
+
 	/*
 	 * 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
 	}
 }
 
@@ -89,6 +100,7 @@ SECTIONS
 #define PT_GNU_EH_FRAME	0x6474e550
 #define PT_GNU_STACK	0x6474e551
 #define PT_GNU_PROPERTY	0x6474e553
+#define PT_GNU_SFRAME	0x6474e554
 
 /*
  * We must supply the ELF program headers explicitly to get just one
@@ -104,6 +116,9 @@ PHDRS
 	dynamic		PT_DYNAMIC	PF_R;
 	note		PT_NOTE		PF_R;
 	eh_frame_hdr	PT_GNU_EH_FRAME PF_R;
+#ifdef KEEP_SFRAME
+	sframe		PT_GNU_SFRAME	PF_R;
+#endif
 	gnu_stack	PT_GNU_STACK	PF_RW;
 	gnu_property	PT_GNU_PROPERTY	PF_R;
 }
diff --git a/arch/x86/entry/vdso/vdso64/Makefile b/arch/x86/entry/vdso/vdso64/Makefile
index bfffaf1aeecc..459f8026531e 100644
--- a/arch/x86/entry/vdso/vdso64/Makefile
+++ b/arch/x86/entry/vdso/vdso64/Makefile
@@ -14,6 +14,7 @@ vobjs-$(CONFIG_X86_SGX)		+= vsgx.o
 
 # Compilation flags
 flags-y				:= -DBUILD_VDSO64 -m64 -mcmodel=small
+flags-$(CONFIG_AS_SFRAME3)	+= -Wa,--gsframe-3
 
 # The location of this include matters!
 include $(src)/../common/Makefile.include
diff --git a/arch/x86/entry/vdso/vdso64/vdso64.lds.S b/arch/x86/entry/vdso/vdso64/vdso64.lds.S
index 5ce3f2b6373a..13e30d3b4827 100644
--- a/arch/x86/entry/vdso/vdso64/vdso64.lds.S
+++ b/arch/x86/entry/vdso/vdso64/vdso64.lds.S
@@ -9,6 +9,10 @@
 
 #define BUILD_VDSO64
 
+#ifdef CONFIG_AS_SFRAME
+# define KEEP_SFRAME
+#endif
+
 #include "common/vdso-layout.lds.S"
 
 /*
-- 
2.51.0

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

[H. Peter Anvin]

On 2026-02-06 11:36, Jens Remus wrote:
> 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?

> 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?

>  	/*
>  	 * 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.

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.

	-hpa

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

[Jens Remus]

On 2/7/2026 12:08 AM, H. Peter Anvin wrote:
> On 2026-02-06 11:36, Jens Remus wrote:
>> 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

> 
>> 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)
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/

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

[H. Peter Anvin]

On 2026-02-09 08:45, Jens Remus wrote:
> On 2/7/2026 12:08 AM, H. Peter Anvin wrote:
>> On 2026-02-06 11:36, Jens Remus wrote:
>>> 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
> 

OK, the linker not handing R_X86_64_PC64 is probably a good enough reason to
discard .sframe.

The x32 ABI and object format is explicitly intended to be as close to the
x86-64 as possible; it even uses the same architectural identifier. That's
pretty much the reason we don't even bother recompiling the objects in the
first place; the 64-bit objects can simply be downconverted from ELF64 to
ELF32. This also means that the compiler doesn't need to support x32, although
objcopy and ld does.

This also means the DWARF data is the one generated for 64 bits.

This works because the following is true for all vdso entrypoints:
	- No vdso entry point access pointers or explicit "long"s *in memory*.
	  (The latter formally violates POSIX for struct timespec, but that
	   was a deliberate decision imposed by Linus at the time the x32 API
	   was defined: "no 32-bit time_t in a new ABI.")
	- No vdso entry point calls system calls that do, either.
	- No vdso entry point takes a *signed* long as an argument.
	- No vdso entry point calls system calls that differ in behavior
	  between x86-64 and x32, making it OK to call the 64-bit system call
	  from an x32 process.

"unsigned long" and pointers *can* be safely passed in argument registers
(because the architecture will zero-extend those registers), and in addition
"signed long" *can* be safely passed as returns.

If ANY of the constraints above were ever violated, OR the binary format would
start diverging to the point that objcopy can't properly convert it, then we
would need to start compiling the x32 binaries separately.


> 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.

I think ld tripping over a bug justifies dropping .sframe at this point. *Make
sure* to document that in the checkin, and add a comment to vdso32.lds.S that
that is the motivation, so that if x32 gains support for .sframe in the future
(which should be simple enough, since the formats are so similar) we don't get
stuck in some kind of cargo cult programming problem.

It also will avoid issues on the off chance .sframe ends up being defined
differently for x32 for some reason, perhaps for consistency with other 32-bit
platforms.


Include the version of binutils which fixed the problem in your comments.


	-hpa



> 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)

This needs to be IS_ENABLED(CONFIG_AS_SFRAME). Otherwise you get either "y" or
"CONFIG_AS_SFRAME", neither of which are what you want.

>  #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

Is "false" supported by all appropriate cpp versions? "0" is probably a safer
choice, and matches the IS_ENABLED() output anyway.

	-hpa

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

[Jens Remus]

On 2/9/2026 8:13 PM, H. Peter Anvin wrote:
> On 2026-02-09 08:45, Jens Remus wrote:
>> On 2/7/2026 12:08 AM, H. Peter Anvin wrote:
>>> On 2026-02-06 11:36, Jens Remus wrote:
>>>> 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
>>
> 
> OK, the linker not handing R_X86_64_PC64 is probably a good enough reason to
> discard .sframe.

For clarification:

Binutils < 2.46 assembler generates SFrame V2, which uses PC32
relocations.
Binutils 2.46+ assembler will generate SFrame V3, which uses PC64
relocations, which the GNU linker will also support for x32.

The intent is to only support SFrame V3 in unwind user sframe and
therefore also only enable .sframe generation in VDSO using SFrame V3.

> The x32 ABI and object format is explicitly intended to be as close to the
> x86-64 as possible; it even uses the same architectural identifier. That's
> pretty much the reason we don't even bother recompiling the objects in the
> first place; the 64-bit objects can simply be downconverted from ELF64 to
> ELF32. This also means that the compiler doesn't need to support x32, although
> objcopy and ld does.
> 
> This also means the DWARF data is the one generated for 64 bits.
> 
> This works because the following is true for all vdso entrypoints:
> 	- No vdso entry point access pointers or explicit "long"s *in memory*.
> 	  (The latter formally violates POSIX for struct timespec, but that
> 	   was a deliberate decision imposed by Linus at the time the x32 API
> 	   was defined: "no 32-bit time_t in a new ABI.")
> 	- No vdso entry point calls system calls that do, either.
> 	- No vdso entry point takes a *signed* long as an argument.
> 	- No vdso entry point calls system calls that differ in behavior
> 	  between x86-64 and x32, making it OK to call the 64-bit system call
> 	  from an x32 process.
> 
> "unsigned long" and pointers *can* be safely passed in argument registers
> (because the architecture will zero-extend those registers), and in addition
> "signed long" *can* be safely passed as returns.
> 
> If ANY of the constraints above were ever violated, OR the binary format would
> start diverging to the point that objcopy can't properly convert it, then we
> would need to start compiling the x32 binaries separately.

Thank you for the detailed explanation!

>> 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.
> 
> I think ld tripping over a bug justifies dropping .sframe at this point. *Make
> sure* to document that in the checkin, and add a comment to vdso32.lds.S that
> that is the motivation, so that if x32 gains support for .sframe in the future
> (which should be simple enough, since the formats are so similar) we don't get
> stuck in some kind of cargo cult programming problem.
> 
> It also will avoid issues on the off chance .sframe ends up being defined
> differently for x32 for some reason, perhaps for consistency with other 32-bit
> platforms.
> 
> 
> Include the version of binutils which fixed the problem in your comments.

Ok, will do.

>> 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)
> 
> This needs to be IS_ENABLED(CONFIG_AS_SFRAME). Otherwise you get either "y" or
> "CONFIG_AS_SFRAME", neither of which are what you want.

Good catch!  Will fix.

> 
>>  #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
> 
> Is "false" supported by all appropriate cpp versions? "0" is probably a safer
> choice, and matches the IS_ENABLED() output anyway.

Will do.  I assumed "true" / "false" would be supported, given there are
a few instances:

  $ git grep "#define.*\(false\|true\)" -- arch/x86/

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/

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

[Jens Remus]

On 2/6/2026 8:36 PM, Jens Remus wrote:
> 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. ]
> 
> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> Signed-off-by: Jens Remus <jremus@linux.ibm.com>

> diff --git a/arch/Kconfig b/arch/Kconfig

> @@ -479,6 +479,13 @@ config HAVE_HARDLOCKUP_DETECTOR_ARCH
>  	  It uses the same command line parameters, and sysctl interface,
>  	  as the generic hardlockup detectors.
>  
> +config AS_SFRAME
> +	bool
> +
> +config AS_SFRAME3
> +	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)

Above tests whether the assembler supports --gsframe-3 to generate
.sframe in SFrame V3 format.  GNU assembler only supports to generate
SFrame for x86-64.  If the assembler is built for i386 (x86-32) the test
will fail unless option --64 is specified.  I wonder whether that could
happen in (the rather hypothetical?) case, when the kernel is cross built
for x86-64 on i386?  Should this therefore be changed to the following?

config AS_SFRAME_64
	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,$(m64-flag) -Wa$(comma)--gsframe)

An alternative would be to enable as-instr64 to accept an optional flag
operand, similar to as-instr, and use as-instr64 instead of as-instr.

Or is this not required, as in a cross build for 64-bit on a 32-bit
platform (or inverse) a respective cross toolchain is a prerequisite and
the m64-flag (or m32-flag) is not used?

I tried to simulate this using docker and an i386 image and then using
the i386 tool in the container to switch "uname -m" to "i686".  But both
of my following attempts to build for x86-64 on i386 fail with fixdep
not found:

$ docker run -it --rm -v "$HOME/linux:$HOME/linux" --platform i386 public.ecr.aws/docker/library/debian:13.3
# sed -i -s 's/^Types: deb/& deb-src/' /etc/apt/sources.list.d/debian.sources
# apt update
# apt -y build-dep linux

# make mrproper
# i386 make ARCH=x86_64 defconfig
# i386 make ARCH=x86_64 arch/x86/entry/vdso/

# make mrproper
# apt -y install gcc-x86-64-linux-gnu
# i386 make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- defconfig
# i386 make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- arch/x86/entry/vdso/

> +	select AS_SFRAME
> +
>  config UNWIND_USER
>  	bool

> diff --git a/arch/x86/entry/vdso/vdso64/Makefile b/arch/x86/entry/vdso/vdso64/Makefile

> @@ -14,6 +14,7 @@ vobjs-$(CONFIG_X86_SGX)		+= vsgx.o
>  
>  # Compilation flags
>  flags-y				:= -DBUILD_VDSO64 -m64 -mcmodel=small
> +flags-$(CONFIG_AS_SFRAME3)	+= -Wa,--gsframe-3

flags-$(CONFIG_AS_SFRAME3_64)	+= -Wa,--gsframe-3

>  
>  # The location of this include matters!
>  include $(src)/../common/Makefile.include
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/

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

[H. Peter Anvin]

On February 10, 2026 8:46:33 AM PST, Jens Remus <jremus@linux.ibm.com> wrote:
>On 2/6/2026 8:36 PM, Jens Remus wrote:
>> 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. ]
>> 
>> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
>> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
>> Signed-off-by: Jens Remus <jremus@linux.ibm.com>
>
>> diff --git a/arch/Kconfig b/arch/Kconfig
>
>> @@ -479,6 +479,13 @@ config HAVE_HARDLOCKUP_DETECTOR_ARCH
>>  	  It uses the same command line parameters, and sysctl interface,
>>  	  as the generic hardlockup detectors.
>>  
>> +config AS_SFRAME
>> +	bool
>> +
>> +config AS_SFRAME3
>> +	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)
>
>Above tests whether the assembler supports --gsframe-3 to generate
>.sframe in SFrame V3 format.  GNU assembler only supports to generate
>SFrame for x86-64.  If the assembler is built for i386 (x86-32) the test
>will fail unless option --64 is specified.  I wonder whether that could
>happen in (the rather hypothetical?) case, when the kernel is cross built
>for x86-64 on i386?  Should this therefore be changed to the following?
>
>config AS_SFRAME_64
>	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,$(m64-flag) -Wa$(comma)--gsframe)
>
>An alternative would be to enable as-instr64 to accept an optional flag
>operand, similar to as-instr, and use as-instr64 instead of as-instr.
>
>Or is this not required, as in a cross build for 64-bit on a 32-bit
>platform (or inverse) a respective cross toolchain is a prerequisite and
>the m64-flag (or m32-flag) is not used?
>
>I tried to simulate this using docker and an i386 image and then using
>the i386 tool in the container to switch "uname -m" to "i686".  But both
>of my following attempts to build for x86-64 on i386 fail with fixdep
>not found:
>
>$ docker run -it --rm -v "$HOME/linux:$HOME/linux" --platform i386 public.ecr.aws/docker/library/debian:13.3
># sed -i -s 's/^Types: deb/& deb-src/' /etc/apt/sources.list.d/debian.sources
># apt update
># apt -y build-dep linux
>
># make mrproper
># i386 make ARCH=x86_64 defconfig
># i386 make ARCH=x86_64 arch/x86/entry/vdso/
>
># make mrproper
># apt -y install gcc-x86-64-linux-gnu
># i386 make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- defconfig
># i386 make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- arch/x86/entry/vdso/
>
>> +	select AS_SFRAME
>> +
>>  config UNWIND_USER
>>  	bool
>
>> diff --git a/arch/x86/entry/vdso/vdso64/Makefile b/arch/x86/entry/vdso/vdso64/Makefile
>
>> @@ -14,6 +14,7 @@ vobjs-$(CONFIG_X86_SGX)		+= vsgx.o
>>  
>>  # Compilation flags
>>  flags-y				:= -DBUILD_VDSO64 -m64 -mcmodel=small
>> +flags-$(CONFIG_AS_SFRAME3)	+= -Wa,--gsframe-3
>
>flags-$(CONFIG_AS_SFRAME3_64)	+= -Wa,--gsframe-3
>
>>  
>>  # The location of this include matters!
>>  include $(src)/../common/Makefile.include
>Thanks and regards,
>Jens

I think we can worry about that later.

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

[Josh Poimboeuf]

On Tue, Feb 10, 2026 at 05:46:33PM +0100, Jens Remus wrote:
> On 2/6/2026 8:36 PM, Jens Remus wrote:
> > 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. ]
> > 
> > Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
> > Signed-off-by: Jens Remus <jremus@linux.ibm.com>
> 
> > diff --git a/arch/Kconfig b/arch/Kconfig
> 
> > @@ -479,6 +479,13 @@ config HAVE_HARDLOCKUP_DETECTOR_ARCH
> >  	  It uses the same command line parameters, and sysctl interface,
> >  	  as the generic hardlockup detectors.
> >  
> > +config AS_SFRAME
> > +	bool
> > +
> > +config AS_SFRAME3
> > +	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,-Wa$(comma)--gsframe-3)
> 
> Above tests whether the assembler supports --gsframe-3 to generate
> .sframe in SFrame V3 format.  GNU assembler only supports to generate
> SFrame for x86-64.  If the assembler is built for i386 (x86-32) the test
> will fail unless option --64 is specified.  I wonder whether that could
> happen in (the rather hypothetical?) case, when the kernel is cross built
> for x86-64 on i386?  Should this therefore be changed to the following?
> 
> config AS_SFRAME_64
> 	def_bool $(as-instr,.cfi_startproc\n.cfi_endproc,$(m64-flag) -Wa$(comma)--gsframe)
> 
> An alternative would be to enable as-instr64 to accept an optional flag
> operand, similar to as-instr, and use as-instr64 instead of as-instr.
> 
> Or is this not required, as in a cross build for 64-bit on a 32-bit
> platform (or inverse) a respective cross toolchain is a prerequisite and
> the m64-flag (or m32-flag) is not used?
> 
> I tried to simulate this using docker and an i386 image and then using
> the i386 tool in the container to switch "uname -m" to "i686".  But both
> of my following attempts to build for x86-64 on i386 fail with fixdep
> not found:
> 
> $ docker run -it --rm -v "$HOME/linux:$HOME/linux" --platform i386 public.ecr.aws/docker/library/debian:13.3
> # sed -i -s 's/^Types: deb/& deb-src/' /etc/apt/sources.list.d/debian.sources
> # apt update
> # apt -y build-dep linux
> 
> # make mrproper
> # i386 make ARCH=x86_64 defconfig
> # i386 make ARCH=x86_64 arch/x86/entry/vdso/
> 
> # make mrproper
> # apt -y install gcc-x86-64-linux-gnu
> # i386 make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- defconfig
> # i386 make ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- arch/x86/entry/vdso/

Hm, I think I broke that with

  a808a2b35f66 ("tools build: Fix fixdep dependencies")

... though it's been broken almost a year, maybe nobody cares.

Regardless, we do need to fix "make clean" and "make mrproper" for
objtool, which would be something like so:

diff --git a/Makefile b/Makefile
index d3a8482bdbd0..ed850044491d 100644
--- a/Makefile
+++ b/Makefile
@@ -1474,6 +1474,15 @@ ifneq ($(wildcard $(resolve_btfids_O)),)
 	$(Q)$(MAKE) -sC $(srctree)/tools/bpf/resolve_btfids O=$(resolve_btfids_O) clean
 endif
 
+PHONY += objtool_clean
+
+objtool_O = $(abspath $(objtree))/tools/objtool
+
+objtool_clean:
+ifneq ($(wildcard $(objtool_O)),)
+	$(Q)$(MAKE) -sC $(abs_srctree)/tools/objtool O=$(objtool_O) srctree=$(abs_srctree) clean
+endif
+
 tools/: FORCE
 	$(Q)mkdir -p $(objtree)/tools
 	$(Q)$(MAKE) O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/
@@ -1637,7 +1646,7 @@ vmlinuxclean:
 	$(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean
 	$(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean)
 
-clean: archclean vmlinuxclean resolve_btfids_clean
+clean: archclean vmlinuxclean resolve_btfids_clean objtool_clean
 
 # mrproper - Delete all generated files, including .config
 #
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index a40f30232929..6964175abdfd 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -29,6 +29,8 @@ srctree := $(patsubst %/,%,$(dir $(CURDIR)))
 srctree := $(patsubst %/,%,$(dir $(srctree)))
 endif
 
+RM ?= rm -f
+
 LIBSUBCMD_DIR = $(srctree)/tools/lib/subcmd/
 ifneq ($(OUTPUT),)
   LIBSUBCMD_OUTPUT = $(abspath $(OUTPUT))/libsubcmd