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

On Thu, Jul 09, 2026 at 12:06:07PM -0700, H. Peter Anvin wrote:
> On July 9, 2026 2:57:09 AM PDT, Vincenzo Frascino <[email protected]> wrote:
> >On 08/07/2026 14:56, 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 <[email protected]>
> >> Link: https://lore.kernel.org/lkml/[email protected]/
> >> Signed-off-by: Thomas Weißschuh <[email protected]>

(...)

> Why stuff them into a tarball?

Because it was the easiest solution to implement and has been sufficient
for IKHEADERS so far. I don't see a clearly winning solution among the
possibilities to expose a directory:

* Use plain sysfs:
  Requires a new code generator and potentially changes to sysfs

* Use a read-only filesystem like cramfs/erofs:
  Introduces new build-time and runtime dependencies

* Add a new filesystem backed by a tarball or cpio archive:
  Lot's of complexity and work to implement

But I am open to discussions and other ideas.


Thomas