From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id A7EB03858434 for ; Thu, 23 Mar 2023 18:40:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A7EB03858434 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-17aeb49429eso23286693fac.6 for ; Thu, 23 Mar 2023 11:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1679596826; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=eMwX/VydMGosgWJ5frr0abKfP3e+SJaMGRwP3PzA78o=; b=c3mpr6wTLTt2bfxzncYD0+i9MBkO9mCVMuJEt0L8Pp5i8SUPnhEZZPgK4gsmTu4xha 7oZ20/pmr2vO1LIoo4kA5tQS4Jmo1qFhszBjRlnAx+caMcZ5KSkdxfADyErVREBka1Mi FQrdqD2P2IxsT9TLEIUJkVgdPF01VWRexIzAlABST57P/rYCvZql0Nos3EjKop5R0Ia0 g1/+RAH36k+amX4O7Y+dg/LyPZe70dZdkiw3/6auKd0bcerv/hHX6SvQD3bdNysx+Pv9 q07/zkCnEv2su1eMApD43yXQzdjvHYLtyQX7Z+5XpN8pLuqoAMI8oBocA+0K6SEodOua /V4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679596826; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eMwX/VydMGosgWJ5frr0abKfP3e+SJaMGRwP3PzA78o=; b=HxM8janmJyibQ1E9/tfPuV/J2OEcQfKzdpBb8gqTHiOYlX7iKIEgBzYrStMRe52ZVx MWoW17f17pUeczrkGzIz/eJfJWcCGotu12tB9FupLaJB9/vY5OOdXCHteuluZAQFD5XZ Oim1skFnJkwcrFcysZKtjTd18LKdw4+OQlt6lTZLnNj/18W1PQ3/iE02hNPO4ShjXmfK DZodgWbaM/bbK2Rpa61dr1hEwF3FH3QxzR88176PVo9u2xzV3IHQVFmEipTEhktDqxIs V4+GxVFb59njhXyoqzaqptaudQb8xlETQ9PyWsToySMIaBpd0rJmamemM+Kr32o/3A+2 n3Mg== X-Gm-Message-State: AAQBX9d6+cynYeYfrpd2Kv9SV1sOyxBjHJCs7sBdv0MNd8GuHUQHOj9Q LldMjbFuFWtSzgihWPyqQLwzHiNHibDjv5K+G2Zbrg== X-Google-Smtp-Source: AK7set+OoHgJYlCTBKLruurYl3Bwl5eLtW7eNV/ARu3fijbCWvxLuPqCgbr9BzOjfY0v6vHisj0bag== X-Received: by 2002:a05:6870:b506:b0:172:7218:9c01 with SMTP id v6-20020a056870b50600b0017272189c01mr2326354oap.2.1679596826006; Thu, 23 Mar 2023 11:40:26 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c0:c260:7930:b4e8:7389:be1f? ([2804:1b3:a7c0:c260:7930:b4e8:7389:be1f]) by smtp.gmail.com with ESMTPSA id zj22-20020a0568716c9600b0017ae6741157sm6474579oab.4.2023.03.23.11.40.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Mar 2023 11:40:24 -0700 (PDT) Message-ID: Date: Thu, 23 Mar 2023 15:40:21 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH] LoongArch: Add Syscall Assembly Implementation Content-Language: en-US To: Xi Ruoyao , Andreas Schwab , caiyinyu Cc: libc-alpha@sourceware.org References: <20230323084013.1100656-1-caiyinyu@loongson.cn> <8a4e2e72-9daf-d264-f49d-719daa2407b5@loongson.cn> <80f6afc82e1b03d69a744e1707131f27995db455.camel@xry111.site> <715a25cdd0fb53c8948e0d782d2149a68a62cbb7.camel@xry111.site> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <715a25cdd0fb53c8948e0d782d2149a68a62cbb7.camel@xry111.site> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 : >>>>>>    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.