[PATCH] LoongArch: Add Syscall Assembly Implementation

[Adhemerval Zanella Netto]

On 23/03/23 15:26, Xi Ruoyao wrote:
> On Fri, 2023-03-24 at 01:34 +0800, Xi Ruoyao via Libc-alpha wrote:
>> On Thu, 2023-03-23 at 21:43 +0800, Xi Ruoyao wrote:
>>> On Thu, 2023-03-23 at 21:34 +0800, Xi Ruoyao wrote:
>>>> On Thu, 2023-03-23 at 14:12 +0100, Andreas Schwab wrote:
>>>>> On Mär 23 2023, caiyinyu wrote:
>>>>>
>>>>>> Without this patch(objdump -d libc.so...):
>>>>>>
>>>>>> 00000000000dd45c <syscall>:
>>>>>>    dd45c:       02fec063        addi.d          $sp, $sp, -
>>>>>> 80(0xfb0)
>>>>>>    dd460:       02c0606c        addi.d          $t0, $sp, 24(0x18)
>>>>>>    dd464:       29c06065        st.d            $a1, $sp, 24(0x18)
>>>>>>    dd468:       29c08066        st.d            $a2, $sp, 32(0x20)
>>>>>>    dd46c:       29c0a067        st.d            $a3, $sp, 40(0x28)
>>>>>>    dd470:       29c0c068        st.d            $a4, $sp, 48(0x30)
>>>>>>    dd474:       29c0e069        st.d            $a5, $sp, 56(0x38)
>>>>>>    dd478:       29c1206b        st.d            $a7, $sp, 72(0x48)
>>>>>>    dd47c:       29c1006a        st.d            $a6, $sp, 64(0x40)
>>>>>
>>>>> If the argument registers are call-clobbbered, why does the compiler
>>>>> need to save them?
>>>>
>>>> It seems triggered by va_start.  If I don't use "..." and replace it
>>>> with "a0, a1, a2, ..., a5", and remove va_start ... va_end, the
>>>> compiled
>>>> code won't save registers.
>>>>
>>>> I'll try to investigate further.
>>>
>>> Similar to GCC PR100955.
>>
>> Nope, it's not PR100955.  PR100955 is about AArch64 but syscall is
>> compiled to almost perfect assemble code on AArch64.
> 
> I was wrong.  AArch64 has a assembly syscall.
> 
>> It looks like caused by the lack of [TARGET_SETUP_INCOMING_VARARGS][1]
>> in GCC config/loongarch.  I'll try to add it...
> 
> LoongArch has a TARGET_SETUP_INCOMING_VARARGS but it does not use the
> information from stdarg pass.  I can fix it, but even with the fix GCC
> would still save 7 registers (now GCC trunk saves 9 registers, the fix
> would make some improvement but no much).
> 
> And the issue seems not trivial to fix.  On x86_64, all of GCC, Clang,
> and MSVC will save some registers if va_arg is used.  I've not found any
> compiler which can avoid saving the va_arg GARs unnecessarily yet:
> 
> https://godbolt.org/z/n1YqWq9c9
> 
> Now to me it seems a bad idea to use va_arg in syscall.c.
> 

I think it was the natural way to express kernel communication mechanism
that indeed takes variadic arguments.   And since it is older than Linux
(man-pages stated it was from 4BSD), it also mean that you don't bind a
maximum limit or arguments (although on Linux and BSD does have a pratical
limit).

We can maybe add a implementation that uses named args (which extra
boilerplate to architectures that accepts 7 arguments instead of usual
6); and just enable it if a per-architecture flag is set meaning that
for that specific ABI the variadic is essentially the same as named
functions calls.  Something like:

long int
syscall (long int number, 
#if __ASSUME_SYSCALL_NAMED_WORKS
         long int a0, long int a1, long int a2,
         long int a3, long int a4, long int a5
#else
         ...
#endif
        )
{
#ifndef __ASSUME_SYSCALL_NAMED_WORKS
  va_list args;
  va_start (args, number);
  long int a0 = va_arg (args, long int);
  long int a1 = va_arg (args, long int);
  long int a2 = va_arg (args, long int);
  long int a3 = va_arg (args, long int);
  long int a4 = va_arg (args, long int);
  long int a5 = va_arg (args, long int);
  va_end (args);
#endif
  long int r = INTERNAL_SYSCALL_NCS_CALL (number, a0, a1, a2, a3, a4, a5);
  if (__glibc_unlikely (INTERNAL_SYSCALL_ERROR_P (r)))
    {
      __set_errno (-r);
      return -1;
    }
  return r;
}

It might need some more hacks to hide the syscall prototype.