From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 68B9F3858428 for ; Sat, 18 Sep 2021 03:16:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 68B9F3858428 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-pg1-x529.google.com with SMTP id t1so11453189pgv.3 for ; Fri, 17 Sep 2021 20:16:06 -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:content-transfer-encoding; bh=LLeuozraIG8eD1sSyCoLi6CmBpVnSr0MRvwDylaYb1g=; b=WpjNFQyyoTY8T6fxguTYEsU7Prs4eQCRjw306Sw/hFwClim0AS3Q+rmdu/Euk0WyO2 47L+1WvV7grsccCkLMot0gEkLxAsklmZ4ZQUwgeSNAzicM+EAIh7EKdGOW5U6oBCYnV+ 6M0/rE+Q8Lnm4othRwHmT9LDoNhVaEQquw0Pol5WhfyIbCsMCPCLGt9182n4j4qQtv/b r5mRign+CBYU0AVf0VmCINHgQa+/ZDa6aP6hQFNRbP8+mSV8ELn/HEULmwfXVDdfaJHn vxNB8KYK34Kyuch/ZQw8duD4NxIUUS4gWUQ8ht7Qh1ZIlk76zBDespPCBmSIA0nmxtD2 NvjQ== 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:content-transfer-encoding; bh=LLeuozraIG8eD1sSyCoLi6CmBpVnSr0MRvwDylaYb1g=; b=z3jR0pEsLAiXl8hOJ5/iFLIDgxqHCe0/ud+y+Qx7Kav2lA5hoFGynJ1Ap2r5hJUtQ+ 7x/Z9usMEfYjjnlF8GzywZPTLCFciY5a4LMkBjFQTF9/kirJjmQ8m/pPHYbR7p6STW1A dmVXO7z5gLMwizaoXCBYCwE+59pLESlb3G+aSpNRaUppxDyzhunxP5JLRb+C0dmsu7Jb OPcdjncsqFJQPMf9+zXQABHaGcY8u94OqWjTUUUchmM2rlN5ULi6xWklSTsln53ZwUYn IwDeKix41rFBh+yaBby4Fqyn6ZsJxeXA5N38y5P7OqgpU8tOqjFYJ3bFDDU1NdFKtzas rcyg== X-Gm-Message-State: AOAM533ZYvPQvPOD4uyGYlYgxdSTt3qwHyFQ1BN9xZQMGVOxzfe7U5Ny w4oocSvA7X9MsOKC9XlXiHgvK1xFHOwHuEJrZAArzYqTExw= X-Google-Smtp-Source: ABdhPJx7Kfw3Feiv3wDxuVXKx5XqHv6gWox+Nry+0sZAxiX5hGcIWR+Kpk+bxsqlqqmoS0DJ+/242O7v7pDOHWqQzDk= X-Received: by 2002:a65:6398:: with SMTP id h24mr12507954pgv.367.1631934965267; Fri, 17 Sep 2021 20:16:05 -0700 (PDT) MIME-Version: 1.0 References: <8AA117E9-6E7C-4D0F-894A-E63EBD40544B@redhat.com> In-Reply-To: <8AA117E9-6E7C-4D0F-894A-E63EBD40544B@redhat.com> From: Vincent Chen Date: Sat, 18 Sep 2021 11:15:54 +0800 Message-ID: Subject: Re: [RFC patch 2/5] RISC-V: Reserve about 5K space in mcontext_t to support future ISA expansion. To: Ben Woodard Cc: Rich Felker , Florian Weimer , GNU C Library , Andrew Waterman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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: Sat, 18 Sep 2021 03:16:07 -0000 On Fri, Sep 17, 2021 at 7:56 AM Ben Woodard wrote: > > I know this patch set mostly deals with signal handling but don=E2=80=99t= forget LD_AUDIT. It has a similar issue for the plt_enter and exit functio= ns. > > -ben Hi Ben, 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. Regards, Vincent > > > On Sep 16, 2021, at 1:03 AM, Vincent Chen wro= te: > > > > =EF=BB=BFOn Mon, Sep 13, 2021 at 9:52 PM Rich Felker = wrote: > >> > >>> On Mon, Sep 13, 2021 at 03:44:09PM +0200, Florian Weimer via Libc-alp= ha wrote: > >>> * Vincent Chen: > >>> > >>>> Following the changes of struct sigcontext in Linux to reserve about= 5K space > >>>> to support future ISA expansion. > >>>> --- > >>>> sysdeps/unix/sysv/linux/riscv/sys/ucontext.h | 2 ++ > >>>> 1 file changed, 2 insertions(+) > >>>> > >>>> diff --git a/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h b/sysdeps/= unix/sysv/linux/riscv/sys/ucontext.h > >>>> index cfafa44..80caf07 100644 > >>>> --- a/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h > >>>> +++ b/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h > >>>> @@ -82,6 +82,8 @@ typedef struct mcontext_t > >>>> { > >>>> __riscv_mc_gp_state __gregs; > >>>> union __riscv_mc_fp_state __fpregs; > >>>> + /* 5K + 256 reserved for vector state and future expansion. */ > >>>> + unsigned char __reserved[5376] __attribute__ ((__aligned__ (16)= )); > >>>> } mcontext_t; > >>> > > Hi Florian and Rich, > > Sorry for the late reply and thank you for reminding me the > > modification will cause ABI break. > > > >>> This changes the size of struct ucontext_t, which is an ABI break > >>> (getcontext callers are supposed to provide their own object). > >>> > > > > The riscv vector registers are all caller-saved registers except for > > VCSR. Therefore, the struct mcontext_t needs to reserve a space for > > it. In addition, RISCV ISA is growing, so I also hope the struct > > mcontext_t has a space for future expansion. Based on the above ideas, > > I reserved a 5K space here. > > > >>> This shouldn't be necessary if the additional vector registers are > >>> caller-saved. > > > > Here I am a little confused about the usage of struct mcontext_t. As > > far as I know, the struct mcontext_t is used to save the > > machine-specific information in user context operation. Therefore, in > > this case, the struct mcontext_t is allowed to reserve the space only > > for saving caller-saved registers. However, in the signal handler, the > > user seems to be allowed to use uc_mcontext whose data type is struct > > mcontext_t to access the content of the signal context. In this case, > > the struct mcontext_t may need to be the same as the struct sigcontext > > defined at kernel. However, it will have a conflict with your > > suggestion because the struct sigcontext cannot just reserve a space > > for saving caller-saved registers. Could you help me point out my > > misunderstanding? Thank you. > > > >> Indeed, that was my first thought when I saw this too. Any late > >> additions to the register file must be call-clobbered or else they are > >> a new ABI. And mcontext_t does not need to represent any > >> call-clobbered state. > >> > >> Rich > > >