Le 27/02/2020 à 01:10, Alistair Francis a écrit : > On Wed, Feb 26, 2020 at 4:02 PM Laurent Vivier <[email protected]> wrote: >> >> Le 26/02/2020 à 20:32, Alistair Francis a écrit : >>> On Tue, Feb 25, 2020 at 3:50 AM Laurent Vivier <[email protected]> wrote: >>>> >>>> Le 25/02/2020 à 00:21, Alistair Francis a écrit : >>>>> Signed-off-by: Alistair Francis <[email protected]> >> ... >>>> I think you can remove following defintion as they should be translated >>>> by the target glibc. >>> >>> glibc won't be exposing these externally, the current plan is just to >>> use this internally to glibc. >> >> But if they are defined internally to glibc, glibc will always translate >> the older ones to the 64bit ones and thus glibc will never use the older >> ones with the kernel, only the 64bit ones, thus the older syscalls >> should never come to QEMU. > > That's part of the problem. QEMU has no TARGET_NR_futex_time64 > support, so we define TARGET_NR_futex to be TARGET_NR_futex_time64.
Ok, I understand the problem. > Looking a bit more it looks like there will still be issues as the > syscall.c makes assumptions on time_t and friends being the word > length (which isn't true for RV32), but this is at least a step in the > right direction. > > Would it be possible to define the type sizes per architecture like glibc > does? The best to do is to define the TARGET_NR_XXX_time64, it will be beneficial for all the targets. We already have functions host_to_target_timespec(), host_to_target_timespec64() and a target__kernel_timespec with 64bit fields. Thanks, Laurent
