From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id DA08D3858D3C for ; Tue, 4 Apr 2023 01:25:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DA08D3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from loongson.cn (unknown [10.20.4.187]) by gateway (Coremail) with SMTP id _____8CxTNqRfCtkp0gWAA--.23114S3; Tue, 04 Apr 2023 09:25:37 +0800 (CST) Received: from [10.20.4.187] (unknown [10.20.4.187]) by localhost.localdomain (Coremail) with SMTP id AQAAf8BxX+SPfCtkoNoUAA--.54755S3; Tue, 04 Apr 2023 09:25:35 +0800 (CST) Subject: Re: [PATCH v2 0/5] linux: Avoid va_list for generic syscall wrappers if possible To: Xi Ruoyao , Carlos O'Donell , libc-alpha@sourceware.org Cc: Wang Xuerui , Adhemerval Zanella Netto , Andreas Schwab , Florian Weimer References: <20230325140815.4170296-1-xry111@xry111.site> <98295b42-c079-c32c-31d6-bb45013342ee@redhat.com> <61ab954501daa24eed8e05638d1c2aec18a941a0.camel@xry111.site> From: caiyinyu Message-ID: Date: Tue, 4 Apr 2023 09:25:35 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <61ab954501daa24eed8e05638d1c2aec18a941a0.camel@xry111.site> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf8BxX+SPfCtkoNoUAA--.54755S3 X-CM-SenderInfo: 5fdl5xhq1xqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoW7ZryxZF4Dtw4fCF47XFWUurg_yoW8Gr18pa y5uFWqkrn5ZF4xArn29FWUZr43ur1rKrW5Jw45KFW8uwn8GryFqr40gay5AF1fuws7G3W2 qr4qqwnrZF9xZaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj qI5I8CrVACY4xI64kE6c02F40Ex7xfYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUU bI8YFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s 1l1IIY67AEw4v_JrI_Jryl8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xv wVC0I7IYx2IY67AKxVW8JVW5JwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwA2z4 x0Y4vEx4A2jsIE14v26r4UJVWxJr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4UJVWxJr1l e2I262IYc4CY6c8Ij28IcVAaY2xG8wAqjxCEc2xF0cIa020Ex4CE44I27wAqx4xG64xvF2 IEw4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_ Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwI xGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUzZ2-UUUUU X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,NICE_REPLY_A,SPF_HELO_PASS,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: 在 2023/3/27 下午10:45, Xi Ruoyao 写道: > On Mon, 2023-03-27 at 10:04 -0400, Carlos O'Donell wrote: > >> In summary, I think this is a compiler problem > Definitely true. > >> and that working around this in glibc >> is going to result in: >> >> - Odd corner case ABI issues between public declarations of variadic >> functions and >>   internal non-variadic definitions. >> >> - Poorer testing of #else code that uses variadic arguments, as the >> public interface >>   requires. >> >> I don't support going in this direction. > Valid reasons.  Abandon this series then. > > But I hope these could be raised earlier (in the discussion about > LoongArch syscall.S) so I wouldn't write all the code :). > >> Is there an alternative that could generate better code that doesn't >> go this way? > For LoongArch I can improve GCC to save only the GARs containing the > arguments really used in va_arg (i.e. one GAR for things like open() or > fcntl() instead of all 8 GARs), but I guess the patch will be delayed > into GCC 14. > > Generally I've not got an idea about how to make GCC avoid saving GARs > unnecessarily with va_arg. So I believe that the assembly implementation of syscalls is still necessary, especially for users who are using GCC<=13. patch: https://sourceware.org/pipermail/libc-alpha/2023-March/146588.html >