perf tools build broken for RISCV 32 bit

[Emiliano Ingrassia]

Hi Arnd,

On Wed, Jan 20, 2021 at 04:29:02PM +0100, Arnd Bergmann wrote:
> On Wed, Jan 20, 2021 at 3:44 PM Emiliano Ingrassia
> <ingrassia at epigenesys.com> wrote:
> > On Tue, Jan 19, 2021 at 08:47:59PM +0100, Arnd Bergmann wrote:
> > > On Tue, Jan 19, 2021 at 5:53 PM Emiliano Ingrassia
> > >
> > > I didn't think that COMPAT_32BIT_TIME was even allowed on rv32,
> > > but it seems there is a bug in Kconfig, it should be disabled for any
> > > architecture that does not set __ARCH_WANT_TIME32_SYSCALLS,
> > > but this should not affect the problem at hand.
> >
> > Ok, will you submit a patch for this bug?
>
> Sure, will do.
> >
> > Here is the example futex app corrected w.r.t. all the previous
> > considerations:
> >
> > |#include <features.h>
> > |#if (defined __GLIBC__) && (__GLIBC__ >= 2 && __GLIBC_MINOR__ >= 32)
> > |#include <asm/unistd.h>
> > |#include <bits/timesize.h>
> > |# ifndef __NR_futex
> > |#  if defined (__NR_futex_time64) && (__TIMESIZE == 64)
> > |#   define __NR_futex  __NR_futex_time64
> > |#  endif
> > |# endif
> > |#endif
>
> This is broken on musl (which does not define __GLIBC__), on kernels
> running with CONFIG_COMPAT_32BIT_TIME disabled (which may
> define __NR_futex, but always returns -ENOSYS), and on any future glibc
> with 64-bit time_t on anything other all existing architectures (which
> define __NR_futex but expect an incompatible argument). It may also
> be broken on rv32 if we end up adding support for futex() in the future,
> as has been discussed as a possible workaround.

I agree on this. It was just an example on howto get __NR_futex defined
in this specific case. Sure is broken in general.

>
> > > rv32 is in the unfortunate position of being the first one that has a glibc
> > > port, so it hits a lot of problems that other architectures do not.
> > > If the applications get fixed properly, then at least they will also
> > > work with musl-1.2 and a (will work-in-progress) glibc that will
> > > eventually allow building with 64-bit time_t.
> >
> > Ok, so in case of perf we probably should limit the needed patch to
> > riscv 32 bit architecture, unless we want to solve the problem for all
> > 32 bit architecture with time_t 64 bit support.
>
> No, whatever you do should be written to work on all 32-bit
> architectures. It would be crazy to add a special case for one
> architecture when it's easier to fix it properly.
>
> What was wrong with the helper function I suggested?

Sorry, I was just trying to have a more clear picture of the problem.

I'm totally fine with the helper function you proposed. About that,
should such approach be used for every time64 syscall for which is known
that there is no libc wrapper?

>
>        Arnd

Thank you, best regards.

Emiliano