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 805243858D1E for ; Wed, 2 Feb 2022 13:08:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 805243858D1E Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 1647B34ECF1; Wed, 2 Feb 2022 08:08:56 -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 iTcKd-Q8oOys; Wed, 2 Feb 2022 08:08:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.efficios.com (Postfix) with ESMTP id 9A13334ECF0; Wed, 2 Feb 2022 08:08:55 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.efficios.com 9A13334ECF0 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 GwcRLFcMm8Lg; Wed, 2 Feb 2022 08:08:55 -0500 (EST) Received: from mail03.efficios.com (mail03.efficios.com [167.114.26.124]) by mail.efficios.com (Postfix) with ESMTP id 7CEBE34EEEE; Wed, 2 Feb 2022 08:08:55 -0500 (EST) Date: Wed, 2 Feb 2022 08:08:55 -0500 (EST) From: Mathieu Desnoyers To: Florian Weimer Cc: Chris Kennelly , Paul Turner , Peter Oskolkov , libc-alpha , linux-kernel , Peter Zijlstra Message-ID: <770517862.27112.1643807335312.JavaMail.zimbra@efficios.com> In-Reply-To: <1375227765.27051.1643801804042.JavaMail.zimbra@efficios.com> References: <432231420.24682.1643727496135.JavaMail.zimbra@efficios.com> <87mtja1fuz.fsf@oldenburg.str.redhat.com> <875ypx1x0d.fsf@oldenburg.str.redhat.com> <1375227765.27051.1643801804042.JavaMail.zimbra@efficios.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: bfYiCaJUUsTdq41BtJE3Fb9JJIH1YGMmnFBS 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 13:08:58 -0000 ----- On Feb 2, 2022, at 6:36 AM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote: > ----- 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 ? More to the point: is ptrdiff_t the correct type here ? I think so. Do we want to revert the ABI and wait another 6 months before we bring back rseq into glibc just for this ? I'm not sure this limitation justifies it. So if there is a quick way to fix that before the official 2.35 release, I'm all for it, otherwise I cannot say that __rseq_offset being an "int" rather than a "ptrdiff_t" will make much real-life difference (unless I'm proven wrong). But we will be stuck with this quirk forever. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com