Re: [PATCH v2 2/2] linux-user/riscv: Update the syscall_nr's to the 5.5 kernel

[Laurent Vivier]

Le 27/02/2020 à 01:10, Alistair Francis a écrit :
> On Wed, Feb 26, 2020 at 4:02 PM Laurent Vivier <address@hidden> wrote:
>>
>> Le 26/02/2020 à 20:32, Alistair Francis a écrit :
>>> On Tue, Feb 25, 2020 at 3:50 AM Laurent Vivier <address@hidden> wrote:
>>>>
>>>> Le 25/02/2020 à 00:21, Alistair Francis a écrit :
>>>>> Signed-off-by: Alistair Francis <address@hidden>
>> ...
>>>> 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