[PATCH v3 08/13] or1k: Linux Syscall Interface

[Adhemerval Zanella]

On 17/12/2021 12:01, Stafford Horne wrote:
> On Thu, Dec 16, 2021 at 06:17:45PM -0300, Adhemerval Zanella wrote:
>>> diff --git a/sysdeps/unix/sysv/linux/or1k/bits/timesize.h b/sysdeps/unix/sysv/linux/or1k/bits/timesize.h
>>> new file mode 100644
>>> index 0000000000..3ab388da7f
>>> --- /dev/null
>>> +++ b/sysdeps/unix/sysv/linux/or1k/bits/timesize.h
>>> @@ -0,0 +1,19 @@
>>> +/* Bit size of the time_t type at glibc build time, OpenRISC version.
>>> +   Copyright (C) 2021 Free Software Foundation, Inc.
>>> +   This file is part of the GNU C Library.
>>> +
>>> +   The GNU C Library is free software; you can redistribute it and/or
>>> +   modify it under the terms of the GNU Lesser General Public
>>> +   License as published by the Free Software Foundation; either
>>> +   version 2.1 of the License, or (at your option) any later version.
>>> +
>>> +   The GNU C Library is distributed in the hope that it will be useful,
>>> +   but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> +   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> +   Lesser General Public License for more details.
>>> +
>>> +   You should have received a copy of the GNU Lesser General Public
>>> +   License along with the GNU C Library; if not, see
>>> +   <https://www.gnu.org/licenses/>.  */
>>> +
>>> +#define __TIMESIZE	64
>>
>> Ok, although I think we should flip the default to 64 bits make
>> old ports to override to 32.
> 
> It makes sense.  It might be a bit tricky as currently __TIMESIZE default is
> __WORDSIZE.  I see a few old ports which have __WORDSIZE 32 and 64 like sparc.

I will fix this upstream, it is just a matter to override to 32 for older ports.

>>
>> Ok, I take that implementing it solely on __or1k_clone is more complex than
>> using a C wrapper.
> 
> I am not to clear what you mean here, I take you are asking why we keep
> __or1k_clone in assembly rather than implement __or1k_clone in C too.
> 
> There are some stack setup bits in __or1k_clone which require assembly.
> 

I meant otherwise in fact, why not implement clone for or1k purely in assembly.