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

[Thomas Weißschuh]

On Fri, Jul 10, 2026 at 11:34:48AM -0700, H. Peter Anvin wrote:
> On July 10, 2026 12:41:31 AM PDT, "Thomas Weißschuh" <thomas.weissschuh@xxxxxxxxxxxxx> wrote:
> >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.

What would be the advantages?

How would this handle the fact that the data page mapping needs to be fixed
next to the code one? Should the data page mapping also be a virtual file?

> >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.
> Why wouldn't it??

I can't reconstruct what I was thinking here. Sorry for the noise.


Thomas