[PATCH 08/12] powerpc: Refactor vsyscall internal macros

[Tulio Magno Quites Machado Filho]

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