3 ms·

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

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 https://man7.org/linux/man-pages/man7/vdso.7.html

mrspuratic 2y ago
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
Joker_vD 2y ago
Oh, so it's like kernel32.dll on the Windows side of things?
- account42 2y ago
  No, kernel32.dll is a real library that is referenced in the import section of executables and libraries that need it.
  - Joker_vD 2y ago
    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.
- mrspuratic 2y ago
  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.

mrspuratic 2y ago

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

Joker_vD 2y ago

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

account42 2y ago
No, kernel32.dll is a real library that is referenced in the import section of executables and libraries that need it.
- Joker_vD 2y ago
  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.
mrspuratic 2y ago
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.