Profiling ArduPilot, I noticed that there were many clock_gettime64() syscalls. I was expecting these to be a vDSO.
At first I couldn't find linux-vdso.so.1, but when I `cat /proc/self/maps`, [vdso] is listed. And if I `hexedit /proc/self/mem`, then seek to [vdso], I can see the elf file, along with strings for __vdso_clock_gettime(), __vdso_clock_gettime64(), __vdso_gettimeofday(), and __vdso_clockgetres(), built by GCC 8.4 Ubuntu/Linaro.
I'm running Linux raspberrypi 6.1.21-v7l+ #1642 SMP Mon Apr 3 17:22:30 BST 2023 armv7l GNU/Linux, gcc (Raspbian 10.2.1-6+rpi1) 10.2.1, on Raspberry Pi 4.
Running this test function with strace shows the system call occurs. Running it on my Debian AMD64 thinkpad does not - vDSO works.
I can step through with GDB to __GI___clock_gettime, but that triggers an ARM "SVC 0" service call instruction with R7=403, which does the clock_gettime() kernel system call. On the AMD64 machine, __GI__clock_gettime() calls clock_gettime() which gets the time through 'rdtscp' instruction. I think Raspberry Pi OS's libc-2.31.so isn't using the vDSO, but why?
At first I couldn't find linux-vdso.so.1, but when I `cat /proc/self/maps`, [vdso] is listed. And if I `hexedit /proc/self/mem`, then seek to [vdso], I can see the elf file, along with strings for __vdso_clock_gettime(), __vdso_clock_gettime64(), __vdso_gettimeofday(), and __vdso_clockgetres(), built by GCC 8.4 Ubuntu/Linaro.
I'm running Linux raspberrypi 6.1.21-v7l+ #1642 SMP Mon Apr 3 17:22:30 BST 2023 armv7l GNU/Linux, gcc (Raspbian 10.2.1-6+rpi1) 10.2.1, on Raspberry Pi 4.
Running this test function with strace shows the system call occurs. Running it on my Debian AMD64 thinkpad does not - vDSO works.
Code:
#include <time.h>int main(){/* find the address of function and data objects */struct timespec tp;return clock_gettime(CLOCK_MONOTONIC, &tp);}Statistics: Posted by rsaxvc — Mon Jan 06, 2025 4:07 am