From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id ACE1F3858413 for ; Thu, 16 Sep 2021 10:21:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ACE1F3858413 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-pf1-x430.google.com with SMTP id y8so5420083pfa.7 for ; Thu, 16 Sep 2021 03:21:16 -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=+7wAn9MNifvll4BH1CsQUXWkpPOprPMikYHrfKbQ0DE=; b=MKP7G68g7gtoeKcETIYd3T6JFyHeJg9yVTr7ETkf0b2DyYs72k1+qRB5Bm2HYRQhGa mF0vy5hYakjqf3NfvKi8tfx1HkY5ByqrYBl6uKCm8Ecgjbxwy9WOuS/a3ie4hcvHP7P2 O2rBW0bAoi6w4WUbdxUTaEexqCXXis+Ie4scZoO/xyZkthC5Q+WwphYWuOmZM5+6gsoX wgL76G5Q8PzdyXMwdHadEg4V3sJkMuZ5JQnq+p9Ft9XSKj3zF9Eiu3sAft+BBy4WFPDr F716+ohfU9Nx1jrxrpBITLJ7Gs0oDiIETv7WUuyofsIInJ6NiCTIdBth9f4+soNZF9TF 94lQ== 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=+7wAn9MNifvll4BH1CsQUXWkpPOprPMikYHrfKbQ0DE=; b=peR+G9vrDOf98PRQK7Ozs/c+sHOVvOcIPceKIk9nLs4hIvah7era0WpioxUhANYDqH D59Ba3kfOGEWoTq0Ka2MX1ANpWiCJwe+/TtGFKFD+sOo7RuvC71Dg3G8GIsMUiKwoq96 Xk6xoLUE25OJeJ1vprpf+w3e92Pb9p3OwCqkBr6iyFbtjOlnrDfnyZrznVM0HQJ2vEh9 xCoj9xvVxg40pY80NQAtlKo/HdDnVM7vSS7ft+zsgDZQMY4wVMV+YnBhJr9WXwOCVODE YtEdhQAa1vBJU/yzRmPU/2uxoVrSt57oqcazlwWntVO1tALqHlcn9nNdZfDSGZDdIVPc mQqw== X-Gm-Message-State: AOAM531Pqm7sZKFOwACDwUagpGY4bAdtK3+ib7y7Et8HmuTQ4On/5OcE dwrryIzLL5yVxR47141Rx6dB5fb7f/+zupY74kKo2A== X-Google-Smtp-Source: ABdhPJzYaAwQY8ieXIoBNdSn8j7ACcfJrNd5fLmtlMmwR49HAgk+d6mVqlbZTDgxSaW2q+pEdmCalAr96ozWu3HQEeY= X-Received: by 2002:a65:6398:: with SMTP id h24mr4196854pgv.367.1631787675570; Thu, 16 Sep 2021 03:21:15 -0700 (PDT) MIME-Version: 1.0 References: <1631497278-29829-1-git-send-email-vincent.chen@sifive.com> <1631497278-29829-6-git-send-email-vincent.chen@sifive.com> <87a6ket90x.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Vincent Chen Date: Thu, 16 Sep 2021 18:21:04 +0800 Message-ID: Subject: Re: [RFC 5/5] RISC-V: Expand PTHREAD_STACK_MIN to support RVV environment To: "H.J. Lu" Cc: Florian Weimer , Joseph Myers , GNU C Library , Andrew Waterman Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 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: Thu, 16 Sep 2021 10:21:18 -0000 On Wed, Sep 15, 2021 at 10:31 PM H.J. Lu wrote: > > On Wed, Sep 15, 2021 at 3:42 AM Florian Weimer via Libc-alpha > wrote: > > > > * Joseph Myers: > > > > > On Mon, 13 Sep 2021, Vincent Chen wrote: > > > > > >> In order to support all pthread operations in the RVV environment, here > > >> PTHREAD_STACK_MIN is set to 4 times GLRO(dl_minsigstacksize), and the > > >> default PTHREAD_STACK_MIN is expanded to 20K bytes. > > > > > > A change to PTHREAD_STACK_MIN has been considered an ABI change in the > > > past, requiring new symbol versions for pthread_attr_setstack and > > > pthread_attr_setstacksize to ensure that binaries built with the old > > > PTHREAD_STACK_MIN definition continue to work rather than failing because > > > the old size is too small. You may need symbol versioning updates for > > > those functions in RISC-V if you make such a change. (All the existing > > > versioning support for this in architecture-independent files assumes the > > > change in value was done before libpthread was merged into libc, so there > > > will be some extra work involved in being the first architecture to > > > increase PTHREAD_STACK_MIN after that merge.) > > Hi Joseph, I understood. I will add symbol versioning to pthread_attr_setstack and pthread_attr_setstacksize functions if I decide to change the PTHREAD_STACK_MIN definition. Thank you. > > Instead it may make sense to leave PTHREAD_STACK_MIN as is and switch to > > the dynamic version (same for the SIGSTKSZ constants). > > > > I don't know what problem RISC-V ran into. It should be fixed with: > Hi Florian and H.J. Lu, The dynamic version works for RISC-V. However, I am afraid that some existing programs, such as nptl/tst-minstack-cancel, do not define _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE. In this case, the original PTHREAD_STACK_MIN definition is too small to support V extension. Therefore, I finally decided to extend PTHREAD_STACK_MIN to 20K for normal use cases. > commit 5d98a7dae955bafa6740c26eaba9c86060ae0344 > Author: H.J. Lu > Date: Mon Jun 21 12:42:56 2021 -0700 > > Define PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN) > > The constant PTHREAD_STACK_MIN may be too small for some processors. > Rename _SC_SIGSTKSZ_SOURCE to _DYNAMIC_STACK_SIZE_SOURCE. When > _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined, define > PTHREAD_STACK_MIN to sysconf(_SC_THREAD_STACK_MIN) which is changed > to MIN (PTHREAD_STACK_MIN, sysconf(_SC_MINSIGSTKSZ)). > > Consolidate with to > provide a constant target specific PTHREAD_STACK_MIN value. > > Reviewed-by: Carlos O'Donell > For this patch, I really appreciate H.J. Lu for providing this feature in glibc. It's really helpful. But, I have a little question. If possible, could H.J. Lu help me clarify it? In __get_pthread_stack_min(), when GLRO(dl_minsigstacksize) !=0 and GLRO(dl_minsigstacksize) > PTHREAD_STACK_MIN, the pthread_stack_min will be set to GLRO(dl_minsigstacksize). However, If my understanding is correct, the size of GLRO(dl_minsigstacksize) approximately equals the size of the signal context. In this case, the remaining free stack seems not enough for GCC to execute unwind if this pthread is terminated by pthread_cancel, such as the case in tst-minstack-cancel.c. Therefore, my question is that the PTHREAD_STACK_MIN does not need to reserve the space for GCC to execute unwind? Thank you in advance. Regards, Vincent