Hacker News Reader

Comment by dividuum | Hacker News Reader

linux-vdso.so.1 isn't a real library you'll find anywhere in the file system and it's not referenced within the ELF file, so libtree doesn't know about it. Instead it is mapped into the address space of a newly started process automatically by the kernel. It's an optimization feature to avoid syscall overhead for function like gettimeofday. See https://man7.org/linux/man-pages/man7/vdso.7.html

View on HN

If you compile the Linux kernel you will have in the build directory the actual .so file(s) which are ultimately embedded in the kernel. They don't ever get installed as conventional libraries (since they are not), but they are otherwise real shared dynamic ELF binaries. If you're curious you can make a copy:

1. grab the vdso offset XX in memory of, for example, the running shell

    gawk -n -vFS=- '/\[vdso\]/{printf("%i",("0x"$1)/4096)}' /proc/$$/maps

2. extract that page

    dd if=/proc/$$/mem of=linux-vdso.so bs=4096 count=1 skip=XX

where XX is the offset from step 1

3. check with

    nm -D linux-vdso.so

    objdump -ad -j .text linux-vdso.so

Oh, so it's like kernel32.dll on the Windows side of things?

No, kernel32.dll is a real library that is referenced in the import section of executables and libraries that need it.

Well, yes, it is a real file, but it is always mapped (at least it used to) into every process' memory space, even if you don't import it explicitly, and it provides a user-space layer above the low-level syscalls.

linux-vdso.so is mostly about sharing a data page so syscalls can be optimised away. It's not for all the kernel API entry points (and it's userland specific so the VDSO varies with the libc version according to which features it optimises in this way). For the specific example above gettimeofday() - each process can read the clock value straight out of the shared VVARS page mapped into its space, no expensive context switch.

Reply on news.ycombinator.com