From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 6FE463858D32 for ; Mon, 15 Apr 2024 11:41:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FE463858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6FE463858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713181313; cv=none; b=ZsDp6qZ/0l7EuME2RrgWFwUJKYX9sHNjQAqwL+3r/b6oC+cefUpcXY7TPe+L/I9Kcd1X5ufyoE9eyg/xcHaTu7ImQ0TOry1IOjEKv5d4y+2DZBI6G+rHZTEA27eNc40oMrVh61Wd2bzHgaC3onAujf9cU/GiyeK7p8EKfAyQK/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713181313; c=relaxed/simple; bh=8qZXLy8owEEVqQs/mhc3uGEWwShErFlUVEWhjkrMyH4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=Xc37p5fQPrUcJIx2mA4WUQOrinb/HzMyZmAzkiyJR7HGRyuKU2PDekP6mmPOnBjFzxDJS1wvqPsDma6VDT6mnN30ltzCBpYWgnEFaMXVZ4vzo68GCatPyig1+ygt47BSCx0G4m20IeaLemhIv1LOjlkin15dzoLhNUdpYk2S5/E= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1713181311; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=9ZCjcGNlge2lyOtjqArJPPC3tV/USE0k+/QND/0acVo=; b=a/2Bzp4mgFD2Tu6QEaSN+LiFEZRkwH5jYzslTZykzhpjxQosAbkQyTpG231UG4XxITz3Ko XHDp4eWKhiJ5II10gWGetSu+8pL5zkyeFJiOK4z2kmSw4R39y+6mRlyMrWDI0x+pEHC+CK XC9AU7lUOcedyRWVR6d5Yphpb7gAFzI= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-563-DAg-gMTXNNSYBCkN-WJ-Qw-1; Mon, 15 Apr 2024 07:41:49 -0400 X-MC-Unique: DAg-gMTXNNSYBCkN-WJ-Qw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id D9698805918; Mon, 15 Apr 2024 11:41:48 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.229]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 83B292BA; Mon, 15 Apr 2024 11:41:46 +0000 (UTC) From: Florian Weimer To: enh Cc: Fangrui Song , Adhemerval Zanella Netto , Szabolcs Nagy , Cristian =?utf-8?Q?Rodr=C3=ADguez?= , "H.J. Lu" , libc-alpha@sourceware.org, Vitaly Buka , Fangrui Song , Evgenii Stepanov , Kostya Serebryany , Dmitry Vyukov Subject: Re: [PATCH] aarch64: Remove ld.so __tls_get_addr plt usage In-Reply-To: (enh@google.com's message of "Wed, 10 Apr 2024 08:46:57 -0700") References: <20240405123550.1748641-1-adhemerval.zanella@linaro.org> <87a5m14odr.fsf@oldenburg.str.redhat.com> Date: Mon, 15 Apr 2024 13:41:29 +0200 Message-ID: <87ttk2n992.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > bionic implemented > https://sourceware.org/glibc/wiki/ThreadPropertiesAPI in > https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/include/sys/thread_properties.h > but tbh i'm not sure that the sanitizer folks moved over to the new > api? I think I wrote about this before: The APIs are underspecified. I think we want to be able to change the boundaries of static TLS eventually (allocating more backing storage before the start or the end, using address space that previously was only reserved with PROT_NONE). Maybe I should put it into the wiki page. > (i don't think we could just use malloc() because jemalloc -- which we > still haven't fully removed for very low-end users in favor of scudo > -- was itself using TLS thread locals? scudo has its own reserved > constant slot in bionic, so that should be fine, i think, but we're > not there yet.) Yes, that's the TCB bootstrap problem I mentioned. It's only relevant to the initial thread. There is no functional requirement to allocate TCBs directly on the thread they are used for. So once we solve the TCB issue for the main thread (and have a mode that uses malloc otherwise), I think we are done. Thanks, Florian