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

[Thomas Weißschuh]

On Fri, Jul 10, 2026 at 12:32:55AM -0700, H. Peter Anvin wrote:
> On July 9, 2026 11:36:25 PM PDT, "Thomas Weißschuh" <thomas.weissschuh@xxxxxxxxxxxxx> wrote:
> >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 <vincenzo.frascino@xxxxxxx> 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 <tglx@xxxxxxxxxx>
> >> >> Link: https://lore.kernel.org/lkml/20260602090536.045586688@xxxxxxxxxx/
> >> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> >
> >(...)
> >
> >> 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.
> 
> I discussed this with GregKH a while ago, in the context of eventually making
> the vdso an actual mapping of a virtual file. According to him it should be
> quite simple in sysfs; I got a bit stumped on the necessary hooks (the kernel
> needs to keep track of where the vdso lives in the address space.)

Interesting idea, I will take a look at it.

Today the vDSO mapped into userspace is a stripped version. For the
debugging usecase however we want the unstripped one.
Also it won't help with debugging a coredump.


Thomas