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

[Thomas Weißschuh]

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@xxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx>
> >> >> Link: https://lore.kernel.org/lkml/20260602090536.045586688@xxxxxxxxxx/
> >> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> >> >> ---
> >> >>  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