Re: [patch 8/8] x86/vdso: Implement __vdso_futex_robust_try_unlock()

[Florian Weimer]

* Thomas Weißschuh:

> On Wed, Mar 18, 2026 at 05:17:38PM +0100, Thomas Gleixner wrote:
>> On Tue, Mar 17 2026 at 12:17, Thomas Weißschuh wrote:
>> >> Due to my pretty limited userspace DSO knowledge that was the best I
>> >> came up with. If you have a better idea, please let me know.
>> >
>> > I would have expected GDB to be able to use the separate vDSO debugging
>> > symbols to find these symbols. So far I was not able to make it work,
>> > but I blame my limited GDB knowledge.
>> 
>> I got it "working" by manually loading vdso64.so.dbg at the right
>> offset, which only took about 10 attempts to get it right. Then you can
>> use actual local symbols.
>> 
>> vdso2c picks them up correctly too.
>
> What also works is to have GDB look up the debug symbols through their
> debug ids. At this point the load address of the vDSO is already known.
>
> $ make vdso_install INSTALL_MOD_PATH=$SOME_DIRECTORY
> $ gdb -ex "set debug-file-directory $SOME_DIRECTORY/lib/modules/$(uname -r)/vdso" $BINARY
>
> Depending on the distribution the vDSO from the kernel package might already
> be set up to be found automatically.
>
> Maybe we could add a helper to scripts/gdb/ which uses $(vdso-install-y)
> to either populate a debug-file-directory automatically or hook into the GDB
> lookup process to avoid these manual steps.

If the the /lib/modules/$(uname -r)/vdso/vdsoNN.so path is standard, we
can use it in the link map, at the expense of an additional system call
during process startup.  It isn't just a performance cost.  We've seen
seccomp filters that kill the process on uname calls.

Thanks,
Florian