[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Laurent Vivier
Subject: Re: [PATCH v2 2/2] linux-user/riscv: Update the syscall_nr's to the 5.5 kernel
Date: Thu, 27 Feb 2020 01:41:05 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]