On Tue, Nov 11, 2025, at 11:49, Thomas Weißschuh wrote:
> The 32-bit time variants on musl have different names, provide a fallback.
>
> Signed-off-by: Thomas Weißschuh <[email protected]>
> ---
> tools/testing/selftests/vDSO/vdso_test_abi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/testing/selftests/vDSO/vdso_test_abi.c
> b/tools/testing/selftests/vDSO/vdso_test_abi.c
> index
> bb5a5534ae7e8a46d7e68a561684c29a752b866d..0a6b16a21369642384d43b0efd1bca227a2a4298
>
> 100644
> --- a/tools/testing/selftests/vDSO/vdso_test_abi.c
> +++ b/tools/testing/selftests/vDSO/vdso_test_abi.c
> @@ -166,7 +166,11 @@ static void
> vdso_test_clock_getres(__kernel_clockid_t clk_id)
> clock_getres_fail++;
> }
>
> +#ifdef SYS_clock_getres
> ret = syscall(SYS_clock_getres, clk_id, &sys_ts);
> +#else
> + ret = syscall(SYS_clock_getres_time32, clk_id, &sys_ts);
> +#endif
>
I think this #ifdef check is not reliable enough and may hide
bugs. As with the other syscalls, the best way to call these
is to either use __NR_clock_getres_time64 on __kernel_timespec, or
to use __NR_clock_getres on __kernel_old_timespec.
If we are trying to validate the interface here, we should probably
call both if available. If we just want to know the result and
trust that both work correctly, I'd always use __NR_clock_getres_time64
on 32-bit systems and __NR_clock_getres on 64-bit systems.
Arnd
