From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) by sourceware.org (Postfix) with ESMTPS id 3FD803858D33 for ; Wed, 22 May 2024 15:40:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3FD803858D33 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3FD803858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::731 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716392432; cv=none; b=qbE3IA3YGQmdjCCTfPoB1az9VWivUtTmUYaZTm8MAmkbgmccZivbfnYA2Qfl3jF6L2GVOEY+iu1wuhXLFpBWyaakRIjSqwz6YyuleW6wOOglIBhhJMhsgMliD2PlHZOqsGMp0VVFNiScD3rM43sxKcPAYJ4Zch+KuLK5rxrVikc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1716392432; c=relaxed/simple; bh=vcaUqNfTtOMKDURzkYUOuYnzNi05+QxHchOddeAPbbo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=qPj3sYKM62usNd0Wi0MaOLyuq6b7IBkOCXLBGgyGJZTaJw0CEYWhP0jIFI9oFFY1KMjgJkmvwc0QUDrrbSlN/mgJlYZ+/2p1QG1Tl6cLaWjfSYVbUWsoAkXkx13t5oqAHAyFpuvBcqZq/Khkxc1TKWj0pBE+Dt/VLtITb98jgZo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-792bf1a4f75so449371385a.2 for ; Wed, 22 May 2024 08:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716392429; x=1716997229; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F2Gu4ah2T9SXP1h4xbY72nG+7HQ8z6P2mCYH8eE0syM=; b=rl80i/KRaFsKxO+mjIM612sHyeprihkskU3/yquA7Yw7i7/aB+gdPzIrb/+fzaVFqS ITsCK9r9N3c0xSu9Ns3REClil5Fe9ZRTGHqjN+5Rh/cKVVsQdH9qR0kYJImH4VF4qARx ydi3c/zXZUGUGBBGBAJPmlJ89I6bpkPJrILpEOcKuvGVJNYDVcMy/vY4QqW6stliaFf9 mRlGtGvWhWqCWzStMyHOeFc0U+R1pAPJXwQQddp5Cz/TFrZCet5dLGw0U8PdrGbvBcE/ 1cIC/jsojt++Fkp4zYQrEMZl2e8bqRduQVtIyaan0oUduostwCMhMTpqVfrCcRyNE2vL +F7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716392429; x=1716997229; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F2Gu4ah2T9SXP1h4xbY72nG+7HQ8z6P2mCYH8eE0syM=; b=AG/62RJUZ16wWzqSS9dEwHzMZmw7eHt74iO281DDNIDB3mHUaqboQTzZbNsscERT+f qr8OHLq1XrnjOnOFFBKYj1tiRatyY9uPWt5zBlILbiIvqWYMpL1CfgQJ3x9A1TJB6BKw /rlZzLS5ZYhOeM0QhV+xQMzf9lepRxKCP5V7EaJPUP/AkJqtUiRP4cpK4WZ82zch6LmQ /0dN+QonKNywGSqVL2S7VH+bDsghGqcmiVjFSjkhLvYawH8FoNQrhGmHYA+IDuyWn0b8 66EQAqBRIcddXvvwP9JNtdKhAIrVFJPVWGToWyX52IdZkJifkmGzibIMWg+KVdA+UKUl ZuUw== X-Forwarded-Encrypted: i=1; AJvYcCV1UaVPmWj5niixE2GiZnLRiCMGzpbSoGvJzFTSMrWFj0KDnf9JYgf3UF91ShovmGlL1rDxRzE+m8XOTeDtclP4FN6HmNMuWDdP X-Gm-Message-State: AOJu0Yx6G0ZsfK1Ndckt6fniF/aGRsg7oSCf5ZiobeAB/Dq4h5r4TErn WuqSO7gJ7F6AcccRQAqAgwecdzfuo6zyrPqJvXsx1JjtG1twdRtIi+h9nuexFiSnUCPKb00Oemx /sVFbxF8oFuOB7jf0jppCZ1Q3uotU1oDCWuxW X-Google-Smtp-Source: AGHT+IGC7GB7er1FqMKKez2DlJxJiUh0tzFcx/guhic/NcYo+9QafsiiCC+JP24r2wnfGzIa9/RUZHcdM3Nj4riYk1w= X-Received: by 2002:a05:6214:5887:b0:6ab:6d5f:d351 with SMTP id 6a1803df08f44-6ab809198damr21754576d6.55.1716392429331; Wed, 22 May 2024 08:40:29 -0700 (PDT) MIME-Version: 1.0 References: <20240405123550.1748641-1-adhemerval.zanella@linaro.org> <87a5m14odr.fsf@oldenburg.str.redhat.com> <87ttk2n992.fsf@oldenburg.str.redhat.com> In-Reply-To: <87ttk2n992.fsf@oldenburg.str.redhat.com> From: enh Date: Wed, 22 May 2024 11:40:18 -0400 Message-ID: Subject: Re: [PATCH] aarch64: Remove ld.so __tls_get_addr plt usage To: Florian Weimer Cc: Fangrui Song , Adhemerval Zanella Netto , Szabolcs Nagy , =?UTF-8?Q?Cristian_Rodr=C3=ADguez?= , "H.J. Lu" , libc-alpha@sourceware.org, Vitaly Buka , Fangrui Song , Evgenii Stepanov , Kostya Serebryany , Dmitry Vyukov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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: On Mon, Apr 15, 2024 at 7:41=E2=80=AFAM Florian Weimer = wrote: > > > 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. TIL that the "tests" don't _build_, let alone pass. speaking of "underspecified", the implementation and tests for __libc_register_thread_exit_callback() disagree about whether or not the _main_ thread exiting should cause the callbacks to be run. (the implementation only calls them for pthread_create() threads, but the test creates no threads and expects the callbacks to have run.) given that there's no argument to the callback to identify _which_ thread exited, i'm not entirely sure how this was intended to be used anyway? is it useful to know "something exited"? (afaict no llvm sanitizer is using this.) > > (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 >