From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.efficios.com (mail.efficios.com [167.114.26.124]) by sourceware.org (Postfix) with ESMTPS id 5B9E43853812 for ; Wed, 2 Feb 2022 11:36:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5B9E43853812 Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id B785434EB03; Wed, 2 Feb 2022 06:36:44 -0500 (EST) Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BcjIfy6EbqW3; Wed, 2 Feb 2022 06:36:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 3A12B34E92B; Wed, 2 Feb 2022 06:36:44 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 3A12B34E92B X-Virus-Scanned: amavisd-new at efficios.com Received: from mail.efficios.com ([127.0.0.1]) by localhost (mail03.efficios.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2orB1KVM8yug; Wed, 2 Feb 2022 06:36:44 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 2BAFA34E9AD; Wed, 2 Feb 2022 06:36:44 -0500 (EST) Date: Wed, 2 Feb 2022 06:36:44 -0500 (EST) From: Mathieu Desnoyers To: Florian Weimer Cc: Chris Kennelly , Paul Turner , Peter Oskolkov , libc-alpha , linux-kernel , Peter Zijlstra Message-ID: <1375227765.27051.1643801804042.JavaMail.zimbra@efficios.com> In-Reply-To: <875ypx1x0d.fsf@oldenburg.str.redhat.com> References: <432231420.24682.1643727496135.JavaMail.zimbra@efficios.com> <87mtja1fuz.fsf@oldenburg.str.redhat.com> <875ypx1x0d.fsf@oldenburg.str.redhat.com> Subject: Re: Aligning tcmalloc with glibc 2.35 rseq ABI MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [167.114.26.124] X-Mailer: Zimbra 8.8.15_GA_4203 (ZimbraWebClient - FF96 (Linux)/8.8.15_GA_4203) Thread-Topic: Aligning tcmalloc with glibc 2.35 rseq ABI Thread-Index: bfYiCaJUUsTdq41BtJE3Fb9JJIH1YA== X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Wed, 02 Feb 2022 11:36:47 -0000 ----- On Feb 2, 2022, at 3:41 AM, Florian Weimer fweimer@redhat.com wrote: > * Florian Weimer: > >> * Chris Kennelly: >> >>> Thanks for the heads up. >>> >>> I did have a question about whether the new protocol would introduce >>> an extra memory reference while initializing a critical section. >>> >>> * With initial-exec TLS, I can directly reference __rseq_abi. >>> * With the new ABI, I might need to ask glibc for the address of the >>> registered rseq structure in its thread data. >> >> You can write __rseq_offset to a static/hidden variable in an ELF >> constructor, and then use pretty much the same assembler sequences as >> for initial-exec TLS on most architectures. > > And now I'm kind of worried that we should be using ptrdiff_t for > __rseq_offset because that's what the initial-exec relocations use. 8-/ I suspect the underlying question here is: how likely is it that a libc requires an offset of more than 2GB either way from the thread pointer to allocate its rseq thread area on a 64-bit architecture ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com