Thread (21 messages) 21 messages, 2 authors, 2021-01-20

Re: perf tools build broken for RISCV 32 bit

From: Emiliano Ingrassia <hidden>
Date: 2021-01-18 11:36:30
Also in: linux-riscv

Hi Arnd,

sorry for my mistake. Effectively glibc does not provide a wrapper for
futex syscall, so its usage is obviously not a solution.

Following what can be found in glibc riscv sysdep.h file:

|#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?

Best regards,

Emiliano

On Thu, Jan 14, 2021 at 08:16:28PM +0100, Arnd Bergmann wrote:
On Thu, Jan 14, 2021 at 7:38 PM Emiliano Ingrassia
[off-list ref] wrote:
quoted
Hi,

When building perf for RISCV 32 bit (v5.10.7) I got the following

| In file included from bench/futex-hash.c:29:
| bench/futex.h: In function ‘futex_wait’:
| bench/futex.h:37:10: error: ‘SYS_futex’ undeclared (first use in this function); did you mean ‘SYS_tee’?

This issue is similar to the one reported in https://lkml.org/lkml/2019/4/19/631

I found that patching tools/arch/riscv/include/uapi/asm/unistd.h as following:

 #ifdef __LP64__
 #define __ARCH_WANT_NEW_STAT
 #define __ARCH_WANT_SET_GET_RLIMIT
+#else
+#define __ARCH_WANT_TIME32_SYSCALLS
 #endif /* __LP64__ */

solved the problem.

I also found that a similar patch for arch/riscv/include/uapi/asm/unistd.h
was removed in commit d4c08b9776b3, so probably this is not the right way(?).
In short, it won't work, as rv32 does not provide the time32 syscalls.
Your patch will make the application build, but it will not be able to
call futex().

You will in fact run into a related problem on any 32-bit architecture
if CONFIG_COMPAT_32BIT_TIME is disabled, or if you pass a non-NULL
timeout parameter and build with a time64-enabled libc.

The fix in the application is to call either __NR_futex or __NR_futex64
depending on the definition of time_t in the C library. I would recommend
doing it like

#ifdef __NR_futex
#define do_futex (sizeof(time_t) == sizeof(__kernel_long_t)) ? \
         __NR_futex : __NR_futex_time64
#else
#define do_futex __NR_futex
#done

       Arnd
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help