perf tools build broken for RISCV 32 bit

[Emiliano Ingrassia]

Hi,

after some searching I found this patch from Yocto project:

https://www.mail-archive.com/linux-yocto@lists.yoctoproject.org/msg01004.html.

I don't know if it's ever been proposed as mainline patch.

What do you think about it? Could it be the right solution?

Thank you, best regards.

Emiliano

On Mon, Jan 18, 2021 at 03:25:05PM +0100, Emiliano Ingrassia wrote:
> Hi Arnd,
>
> thank you for the quick reply and support.
>
> On Mon, Jan 18, 2021 at 12:56:11PM +0100, Arnd Bergmann wrote:
> > On Mon, Jan 18, 2021 at 12:35 PM Emiliano Ingrassia
> > <ingrassia at epigenesys.com> wrote:
> > > |#if __WORDSIZE == 32
> > > |/* Workarounds for generic code needing to handle 64-bit time_t.
> > > |...
> > > |/* Fix sysdeps/nptl/lowlevellock-futex.h.  */
> > > |#define __NR_futex              __NR_futex_time64
> > >
> > > a possible solution to fix the build of perf tool on RISCV 32 bit could
> > > be the following patch to file tools/arch/riscv/include/uapi/asm/unistd.h:
> > > |+
> > > |+#ifndef __NR_futex
> > > |+#define __NR_futex __NR_futex_time64
> > > |+#endif
> > >
> > > What do you think about it? Could it be a correct solution?
> >
> > No, that would be much worse: __NR_futex must only ever point
> > to the system call that takes the old timespec argument. If you define
> > something like this, it breaks applications that try to do the right thing.
> >
> >        Arnd
>
> OK, but what should be the right solution for RISCV 32 bit in this case?
> Is it a problem in the libc implementation or in RISCV/perf implementation?
>
> Thank you, best regards.
>
> Emiliano