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

On July 10, 2026 12:41:31 AM PDT, "Thomas Weißschuh" <[email protected]> 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" <[email protected]> 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 <[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.
>> 
>> 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

Why wouldn't it??