Re: [PATCH] vDSO, kbuild: Provide vDSO debug variants at runtime

["H. Peter Anvin" <hpa@zytor.com>]

On October 29, 2026 2:40:26 AM PDT, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> wrote:
>On Tue, Oct 27, 2026 at 11:12:26PM -0700, H. Peter Anvin wrote:
>> On October 27, 2026 10:55:04 PM PDT, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> wrote:
>> >On Tue, Oct 27, 2026 at 05:02:52PM -0700, H. Peter Anvin wrote:
>> >> On October 27, 2026 1:22:44 PM PDT, Nicolas Schier <nsc@kernel.org> wrote:
>> >> >On 2026-07-08 15:56 +0200, Thomas Weißschuh wrote:
>> >> >> Finding the debug version of the vDSO is not trivial as there is no common
>> >> >> scheme where it is placed. That's especially problematic for CI testing.
>> >> >> 
>> >> >> The vDSO futex unlock mechanism requires for testing to have access to the
>> >> >> inner labels of the unlock assembly, which are only accessible via the
>> >> >> debug so.
>> >> >> 
>> >> >> Also for general debugging purposes it's convenient to have access to the
>> >> >> debug vDSO at a well defined place.
>> >> >> 
>> >> >> The files are placed in /sys/kernel/vdso_debug.tar.xz. They use the
>> >> >> regular 'make vdso_install' layout, including build-id symlinks to find
>> >> >> the correct file for each process.
>> >> >> 
>> >> >> The design is kept close to the ones of the similar IKCONFIG and IKHEADERS.
>> >> >> 
>> >> >> On x86 the x32 vDSO is derived from the x86_64 one, necessitating an
>> >> >> explicit dependency to avoid errors due to concurrent builds.
>> >> >> 
>> >> >> Suggested-by: Thomas Gleixner <tglx@kernel.org>
>> >> >> Link: https://lore.kernel.org/lkml/20260602090536.045586688@kernel.org/
>> >> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>> >> >> ---
>> >> >>  Makefile            | 33 ++++++++++++++++++++++++++++++++-
>> >> >>  arch/x86/Makefile   |  3 +++
>> >> >>  init/Kconfig        | 10 ++++++++++
>> >> >>  kernel/Makefile     |  1 +
>> >> >>  kernel/vdso_debug.c | 43 +++++++++++++++++++++++++++++++++++++++++++
>> >> >>  5 files changed, 89 insertions(+), 1 deletion(-)
>> >> >> 
>> >> >
>> >> >This seems to have fallen through the cracks; shall it be considered for
>> >> >kbuild-7.5?
>> >
>> >Please don't pick this up just yet. I have a prototype which exposes the
>> >directory through sysfs directly without forcing users to unpack the archive.
>> >If you could take a look at the kbuild bits however, that would be great.
>> >
>> >> A thought: most tools support compressed separate debug information. Would it
>> >> make more sense to have the vdso images with separate, compressed debug data
>> >> in a subdirectory?
>> >
>> >I want to stick to the 'make vdso_install' layout. Maybe that should be
>> >changed to your proposal, too? But what are the specific advantages?
>> >The files are compressed on disk anyways through the module compression.
>
>> The nice thing would be that it would let debug tools use them as-is, and
>> after all we need to make the vdso itself available anyway.
>
>To make sure we are on the same page:
>You propose to make the vDSO mapping a file-based one pointing to sysfs?
>
>This would change the userspace ABI and I can imagine some tools breaking.
>Also it will require a bunch of additional per-architecture logic.
>
>Tools should be able to handle the debug-id symlinks as implemented by my
>current scheme. For regular (real) file backed mappings there is no guarantee
>that the file on disk is still the same version that is mapped by the process.
>
>> As a possible side benefit the user would be able to see the post-patch vdso.
>
>Nice idea.
>
>
>We could go with a combined aproach. First we go with my proposal which works
>with minimal per-architecture logic and already works for most of them as is.
>That can later be extended with per-architecture logic to provide the
>alternative-patched "live" view, file-backed mappings and detached debug symbols.
>
>
>Thomas

I'm not necessarily saying the vma has to work that way, but the contents can be exported as a file regardless.

It might be nice to do that in the long run, but that's a separate project.