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

Thomas Weißschuh <[email protected]> Fri, 24 Jul 2026 16:14:52 +0200
Newsgroups gmane.linux.kernel,gmane.linux.kbuild.devel
Message-ID <20260724160750-9e98ad5d-72b9-416c-8485-6942e0a3c8ec@linutronix.de>
On Wed, Jul 15, 2026 at 09:29:35AM -0300, André Almeida wrote:
> Em 08/07/2026 12:28, André Almeida escreveu:
> > Em 08/07/2026 10:56, Thomas Weißschuh escreveu:
> > > 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 <[email protected]>
> > > Link: https://lore.kernel.org/lkml/[email protected]/
> > > Signed-off-by: Thomas Weißschuh <[email protected]>
> > > ---
> > 
> > Thanks for your patch! Tested in arm64 (qemu) and it worked fine. I was
> > just expecting that the file would be called "vdso.so.dbg", not
> > "vdso.so".

That is due to scripts/Makefile.vdsoinst:

dest := $(install-dir)/$$(patsubst %.dbg,%,$$(notdir $(1)))

> > Tested-by: André Almeida <[email protected]>

Thanks!

> Also, how do you suggest to integrate this with kselftests? Maybe adding an
> untar command to futex/functional/run.sh?

In the current implementation, yes. But it would also be possible to have a
proper virtual directory tree, albeit with higher implementation consts.


Thomas