From: Jens Remus <jremus@linux.ibm.com>
To: "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
bpf@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org,
Josh Poimboeuf <jpoimboe@kernel.org>,
Steven Rostedt <rostedt@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Andrii Nakryiko <andrii@kernel.org>,
Indu Bhagat <indu.bhagat@oracle.com>,
"Jose E. Marchesi" <jemarch@gnu.org>,
Beau Belgrave <beaub@linux.microsoft.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Florian Weimer <fweimer@redhat.com>, Kees Cook <kees@kernel.org>,
"Carlos O'Donell" <codonell@redhat.com>,
Sam James <sam@gentoo.org>, Dylan Hatch <dylanbhatch@google.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
"Steven Rostedt (Google)" <rostedt@goodmis.org>
Subject: Re: [PATCH v8 6/6] x86/vdso: Enable sframe generation in VDSO
Date: Tue, 10 Feb 2026 17:46:33 +0100 [thread overview]
Message-ID: <15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com> (raw)
In-Reply-To: <20260206193642.1580787-7-jremus@linux.ibm.com>
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/
next prev parent reply other threads:[~2026-02-10 16:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 19:36 [PATCH v8 0/6] x86/vdso: VDSO updates and fixes for sframes Jens Remus
2026-02-06 19:36 ` [PATCH v8 1/6] x86/vdso: Fix DWARF generation for getrandom() Jens Remus
2026-02-06 19:36 ` [PATCH v8 2/6] x86/asm: Avoid emitting DWARF CFI for non-VDSO Jens Remus
2026-02-06 19:36 ` [PATCH v8 3/6] x86/asm: Use CFI_* macros in SYM_FUNC_* macros so they can be added to VDSO Jens Remus
2026-02-06 19:36 ` [PATCH v8 4/6] x86/vdso: Use SYM_FUNC_{START,END} in __kernel_vsyscall() Jens Remus
2026-02-06 19:36 ` [PATCH v8 5/6] x86/vdso: Use CFI macros in __vdso_sgx_enter_enclave() Jens Remus
2026-02-06 19:36 ` [PATCH v8 6/6] x86/vdso: Enable sframe generation in VDSO Jens Remus
2026-02-06 23:08 ` H. Peter Anvin
2026-02-09 16:45 ` Jens Remus
2026-02-09 19:13 ` H. Peter Anvin
2026-02-10 14:36 ` Jens Remus
2026-02-10 16:46 ` Jens Remus [this message]
2026-02-10 18:49 ` H. Peter Anvin
2026-02-10 18:50 ` Josh Poimboeuf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com \
--to=jremus@linux.ibm.com \
--cc=Liam.Howlett@oracle.com \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andrii@kernel.org \
--cc=beaub@linux.microsoft.com \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=codonell@redhat.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=dylanbhatch@google.com \
--cc=fweimer@redhat.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=indu.bhagat@oracle.com \
--cc=jemarch@gnu.org \
--cc=jolsa@kernel.org \
--cc=jpoimboe@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=rostedt@kernel.org \
--cc=rppt@kernel.org \
--cc=sam@gentoo.org \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.