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