This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 08/12] powerpc: Refactor vsyscall internal macros
Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> * sysdeps/unix/sysv/linux/powerpc/dl-vdso.h: New file.
> * sysdeps/unix/sysv/linux/powerpc/get_timebase_freq.c
> (get_timebase_freq_fallback): New symbol.
> (__get_timebase_freq): Call vDSO as a function pointer instead of
> arch-specific macros.
> * .../unix/sysv/linux/powerpc/gettimeofday.c (gettimeofday): Use
> get_vdso_symbol.
It's the first time a see a ChangeLog entry starting with '\t* ...'.
Is this really valid?
> diff --git a/sysdeps/unix/sysv/linux/powerpc/sysdep.h b/sysdeps/unix/sysv/linux/powerpc/sysdep.h
> index 20167615c8..cf967a8c33 100644
> --- a/sysdeps/unix/sysv/linux/powerpc/sysdep.h
> +++ b/sysdeps/unix/sysv/linux/powerpc/sysdep.h
> @@ -32,3 +33,12 @@
> # define HAVE_SIGTRAMP_32 "__kernel_sigtramp32"
> # define HAVE_SIGTRAMP_RT32 "__kernel_sigtramp_rt32"
> #endif
> +
> +#ifndef __ASSEMBLER__
> +
> +/* PowerPC vDSO symbols always succeed, so there is no need to emulate a
> + function call and check for CR0.SO value. */
> +#define INTERNAL_VSYSCALL_CALL(funcptr, err, nr, args...) \
> + ({ err = 0; funcptr (args); })
After applying this patch, rt/cpu-clock1 started to fail with:
clock_gettime on reaped PID 26033 clock fffffffffffcd272 => Success
clock_getres on reaped PID 26033 clock fffffffffffcd272 => Success
Both cases are expecting to receive errno = EINVAL instead of Success.
Isn't CR0.SO important?
Reference:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/kernel/vdso64/gettimeofday.S#n190
--
Tulio Magno