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

[Stafford Horne <shorne@gmail.com>]

On Fri, Dec 17, 2021 at 02:41:20PM -0300, Adhemerval Zanella wrote:
> 
> 
> 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.

I see, it could be done but I think it's easier to maintain with the va_arg
parsing and generic set_errno handling being in C.

-Staffford