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

["H. Peter Anvin" <hpa@zytor.com>]

On July 9, 2026 11:36:25 PM PDT, "Thomas Weißschuh" <thomas.weissschuh@linutronix.de> 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@arm.com> 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@kernel.org>
>> >> Link: https://lore.kernel.org/lkml/20260602090536.045586688@kernel.org/
>> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
>(...)
>
>> 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

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.)