From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id C9A953858C2C for ; Fri, 1 Oct 2021 01:43:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C9A953858C2C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pl1-x636.google.com with SMTP id n2so5259480plk.12 for ; Thu, 30 Sep 2021 18:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XJc/nNHTfLYNtKwPQXSXZSXl//lSWleaJhJh1pVeYwM=; b=Z94jCIkUJFLAYeelvxmY4fX/vCpPg61/K6GNjNzh41VSJskWWI+arMZA4oHxd9bKMT DKXCANWRmsH6ZIKU1+baNaxAscEeCZQTfJNZ/jet2eKZEfLmnTF7NdQO5KagfkagTl/b QVI0BSMFQO2ZdPib8bAWm+okxM77DxijKlnWw8VQEZc74lCBplE+QjRs1FZED4Mf4ElI 5Q8HKW7/0NPItPF3ZNEnxJdAlesX+eonoQhYneH2dzyMQJlMrXTR59J96c9nUT2YZa/U /Fu8TqaclIp1dnXV+UG2R6HUvx4u31LxNk3W6CYp/PI4cvPJtQ7XUU7VTUzPkhFV1LG9 8zJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XJc/nNHTfLYNtKwPQXSXZSXl//lSWleaJhJh1pVeYwM=; b=FPE4B0MWvF24KvI/8sKbjkk1rMtKKsKUlGmQayKIgFfL1z1bQHZ6TCVzpOABcG3bdD AZKaQc8Tpv4DO2HHN31iWDoPdn7QWZTGEj8Tx2TJPNFNbfjdhMdNl8Qs+76TtpPzPUeO y/HjusiPSDQCdBKjYp/Xe+rO+U2jdppSPGgVgNBIVMz43O1lpKGNljrfwzhB4oWOk/1v CMh8li1VdteQ+mHUS0PLGKWFbt0n1Yx67jgLFO2/NZvSd/5GnSUwQvg87JoMVmmcyVul 6MwSL+Z9DNaq35yFcOK/rRCpIkK1hZtsaiqhALLjiNMvggnCOEHxX8FIma/VijCDEsPQ DFvg== X-Gm-Message-State: AOAM530UafYYuzy3dkMC+BnZX8QjywDHcSaEEy38kJWAw/ceVffEpV5Q H70RCZ12KPdOCMkxZY3mYOE9G7AZ2ledkvr94HK7vg== X-Google-Smtp-Source: ABdhPJzrRWg51TOIXXLfY9GKrWKfoGVYXJ1INZez2ArYZ77RTIUlzzQyiqKciVXBhEWVa5JDT2lGWItnv+nUpMwipXs= X-Received: by 2002:a17:902:e748:b0:13e:30b:66bb with SMTP id p8-20020a170902e74800b0013e030b66bbmr7060231plf.40.1633052622558; Thu, 30 Sep 2021 18:43:42 -0700 (PDT) MIME-Version: 1.0 References: <87o88nyxz8.fsf@oldenburg.str.redhat.com> In-Reply-To: <87o88nyxz8.fsf@oldenburg.str.redhat.com> From: Vincent Chen Date: Fri, 1 Oct 2021 09:43:31 +0800 Message-ID: Subject: Re: [RFC patch 2/5] RISC-V: Reserve about 5K space in mcontext_t to support future ISA expansion. To: Florian Weimer Cc: DJ Delorie via Libc-alpha , DJ Delorie Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 01 Oct 2021 01:43:45 -0000 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.