From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-5.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1A47E1F8C8 for ; Fri, 1 Oct 2021 12:08:47 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F3F0D3857C6F for ; Fri, 1 Oct 2021 12:08:45 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F3F0D3857C6F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1633090126; bh=b+2QaOjV3AmI7GQ15L1mZQMkpN111Qr8Xw1HIX49YX8=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=oAUuAm/LB3gUecIJoO6vVVUOzra3uUeSFlBQlAq2REBUVuHhIQTxiFzVLROI+n9Dg jMbgIb1fAnNiXujDZcapfnpDGPyGVqwwsDAGHbLkX6ket/LlCKlm+TZeoFIzk+s6Qe O5LcoUhM9cRE91jrGeoIKgDAoWSKJ49iRLKJvnYs= Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) by sourceware.org (Postfix) with ESMTPS id E7C833858C2C for ; Fri, 1 Oct 2021 12:08:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7C833858C2C Received: by mail-vs1-xe31.google.com with SMTP id o124so11010221vsc.6 for ; Fri, 01 Oct 2021 05:08:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b+2QaOjV3AmI7GQ15L1mZQMkpN111Qr8Xw1HIX49YX8=; b=MgIihBvc+vR4cvJR4TlbrNFmr1LADOAa7MT8L7CX09m+TLtFrYCZS2XtogKLD04l4H 49lAcD1iIaSNkw9sIFPt549oBxCOUNFuTYolZcXkoEPoF/5farfQKYg/wnt2hsKH2ePg ONU6XW+SQ9WR1Q+s6omUaE8uUIkP/vHIkHjTBOhD8rKG5SZHwugcshWkEP0p27VwMQus jQfJkI+caUItJoUZz9cGa8PJI+e0WYxpHD1fjQC5/5Ne3LBlkr5XTKw435q0VoghESKw /QZ2BFUTZU+IJh8eUirkrvJzKDg6kwp1xSysRc0sFm9wAhpcBifUglZAi8DZE2Kv4VQ1 hRsw== X-Gm-Message-State: AOAM532+AB31slm99THSRemhsXh6w9o8D7wvolLKJ9GnoEJupfP7wSgr FzYxdi0/96WqZTCmIBXRaM+HXEMrG+GzdQ== X-Google-Smtp-Source: ABdhPJy3QZvnj6CUU0GaYZziGWWtonk0FdBtO8Z/vGN3dEgqT5A10wp0gnlD12kHNG74YzWJj8/R9Q== X-Received: by 2002:a67:fd81:: with SMTP id k1mr3468583vsq.47.1633090106147; Fri, 01 Oct 2021 05:08:26 -0700 (PDT) Received: from ?IPv6:2804:431:c7cb:b338:44a:954f:c861:627b? ([2804:431:c7cb:b338:44a:954f:c861:627b]) by smtp.gmail.com with ESMTPSA id i12sm2992373vkn.12.2021.10.01.05.08.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Oct 2021 05:08:25 -0700 (PDT) Subject: Re: [RFC patch 2/5] RISC-V: Reserve about 5K space in mcontext_t to support future ISA expansion. To: Vincent Chen , Florian Weimer References: <87o88nyxz8.fsf@oldenburg.str.redhat.com> Message-ID: Date: Fri, 1 Oct 2021 09:08:22 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Adhemerval Zanella via Libc-alpha Reply-To: Adhemerval Zanella Cc: DJ Delorie via Libc-alpha Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 30/09/2021 22:43, Vincent Chen wrote: > On Tue, Sep 21, 2021 at 1:10 AM Florian Weimer wrote: >> >> * DJ Delorie via Libc-alpha: >> >>> Vincent Chen writes: >>>> I am not familiar with the mechanism of LD_AUDIT, so I actually do not >>>> know if this modification may have any effect on LD_AUDIT. If >>>> possible, could you briefly introduce the issues for me? Thank you >>>> very much. >>> >>> In general, when function foo() calls DSO function bar(), and bar() is >>> in an object that needs to be loaded from disk, the loader needs to save >>> foo()'s context, do a bunch of work, restore the context, and call >>> bar(). >>> >>> The LD_AUDIT feature adds a lot more "do a bunch of work" both on the >>> foo->bar call, and on the bar->foo return, typically calling some third >>> party functions to process the audit messages. >>> >>> However, if the "do a bunch of work" changes registers that aren't saved >>> in the context, and aren't agreed on as "call clobbered" and thus >>> changeable, problems happen. If foo() expects a register to be >>> preserved across the call to bar(), and the loader and audit functions >>> don't know that and clobber it, foo() breaks. >> >> One point of clarification: >> >> The issue is with register usage for passing argument and return values. >> It's more or less unrelated to whether registers are callee-saved or >> caller-saved. So you need special LD_AUDIT support as soon it's >> possible to pass vector arguments and return values in registers (as >> opposed to memory). >> >> Thanks, >> Florian >> > Thank DJ Delorie and Florian very much for the detailed explanation > and clarification. It is really helpful for me to understand this > problem I have not noticed. Currently, I have some findings. If my > understanding is wrong, please correct me. Thank you. > > The ABI for using vector registers to pass arguments and return value > is under discussion and close to ratification. As far as I know, the > riscv Glibc resolver will have a similar issue to this LD_AUDIT > problem after this new ABI is used. Hsiangkai Wang has sent a patch, > https://sourceware.org/pipermail/libc-alpha/2021-August/129931.html, > to deal with this issue in GLIBC resolver. This patch adds a new tag, > STO_RISCV_VARIANT_CC, to indicate whether the function uses this new > ABI or not. During the relocation process, if STO_RISCV_VARIANT_CC is > set in the st_other field of the symbol being processed, the delayed > binding mechanism will be disabled. It can avoid saving vector > registers before entering the resolver function. > > The LD_AUDIT problem is similar to this because we need to prevent the > auditing function from clobbering the vector registers that store the > argument to pass to the audited symbol. Therefore, I think this patch > can resolve the LD_AUDIT issue as well. > It solves the LD_AUDIT issue by not enabling it, so it won't work with STO_RISCV_VARIANT_CC. It is essentially the same issue we have for AArch64 SVE. It should be a fair approach to just not support it, although it seems that HPC tools does use it extensively for some specific usercases. For SVE case I tried to fix by saving/restoring the required SVE defined registers by ABI argument passing [1], although the ABI does not really defines it (Szabolcs thinks we should save *all* registers). In any case, LD_AUDIT is corner case and I think we can workaround within glibc (since we can use a different runtime trampoline to save/restore the required state). [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=c8315ccd30fcecc1b93a9bc3f073010190a86e05;hp=171fdd4bd4f337001db053721477add60d205ed8