Message-ID: <cb96d2bf-f2eb-46f7-be7b-8e144eda5d75@linux.ibm.com>
Date: Tue, 10 Feb 2026 15:36:14 +0100
From: Jens Remus <jremus@...ux.ibm.com>
To: "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        linux-trace-kernel@...r.kernel.org, bpf@...r.kernel.org,
        x86@...nel.org, linux-mm@...ck.org,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Steven Rostedt <rostedt@...nel.org>,
        Indu Bhagat <indu.bhagat@...cle.com>
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrii Nakryiko <andrii@...nel.org>,
        "Jose E. Marchesi" <jemarch@....org>,
        Beau Belgrave <beaub@...ux.microsoft.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Florian Weimer <fweimer@...hat.com>, Kees Cook <kees@...nel.org>,
        "Carlos O'Donell" <codonell@...hat.com>, Sam James <sam@...too.org>,
        Dylan Hatch <dylanbhatch@...gle.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        David Hildenbrand <david@...nel.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
        Michal Hocko
 <mhocko@...e.com>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        "Steven Rostedt (Google)" <rostedt@...dmis.org>
Subject: Re: [PATCH v8 6/6] x86/vdso: Enable sframe generation in VDSO

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@...nel.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@...ibm.com / jremus@...ux.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/

Powered by blists - more mailing lists