From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by sourceware.org (Postfix) with ESMTPS id 52F233858D29 for ; Thu, 30 May 2024 23:29:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52F233858D29 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 52F233858D29 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::632 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717111747; cv=none; b=ds5xMvF0Q2hYXwW8bwa625UfjFnPu9ncmOLH+HUT4ZZsvraXlOaFTdkeabvXMYMjycEXiFplyrPJyr4n1b6ibRwiS2kOMM+Ai4Lj/uaDeBQAmhwPm1FcSPZpF0fDDAK8OiwIoA2klCQF7bsTNXJ527GjPr8+3Z/ZUO8QlBsgKiM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1717111747; c=relaxed/simple; bh=WDjwVJ+UKkC5jXZN80OOG7dZ2ukgLq2VderyerISlFg=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=LZLC5xeBOGgKNz4z6UByCTRRaUVH+XSZxrpCYwvSpeN8u95y71SnKlLXK7ujWkW3t8ZxMQ1n9ogC7nLcgmx7uscxOW2/8FJvivE891Cc8JPKncVmX7Og9bKP9NBwbiVD+N2294Y2BAaQR0NFGQ+UnrQEwZYstYRHip3Ju3WmTW8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x632.google.com with SMTP id d9443c01a7336-1f61742a024so71625ad.0 for ; Thu, 30 May 2024 16:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1717111743; x=1717716543; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XqEmeXh3A0xy4rQ6CknDxYoszsleRgSfbleEFF4eCRQ=; b=ejmr2RDRfGptAWvBoqWvhH221gaMpZp8GVK0l+v2PfjIxob/xpj6tVl12NDtO8L20+ ZLqQH9vBZ/vZdvWNkVgVEsknjPDEMZ7l8/Lmhna2mnqkhwlVT9vAzKarY8TZoKBrMVsW 13mCRFZEGLAZocQPaqVXkB8tfPUwXjZ+0PdD348+uFZXAfGATn7RoZPrOaxXr8XZhJ8q zsBvcUmWSSEkbs1/Hac2seGxW4cf4wbVMuh3kdFqx42IVzgSZgphAcuB7BarjJo0aC+i gUQyo/P6JBrleFIrQTz5O+k2UCUHbZ0YdPYvsz9/aFYwArlRci2ivRjSbN/xcKJ7FG9D e9Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717111743; x=1717716543; h=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=XqEmeXh3A0xy4rQ6CknDxYoszsleRgSfbleEFF4eCRQ=; b=FNjQ3Mjf3h2E53+mG/dYs3xC0tcrabzltY5xmAbtUtnXC9jZq/HdgZBBLgdxslDxNf 55uTcQaJRuwYht2nsWl5BE/0Jojw6NAj6+avr1kZhdBBVAODEz3BAnTks2gChznX37Kh H31MpfCn0zKxG5zaox5Xpw2indaSf4hJ0WvABLLsq5gn0M/yG7H0/jGSyNxzxow3vG2w Mc2indNKT9p+xdIfduK5VmNVRnZsRk6LG9+KdHbw4RKQbkqeF+5XjxDDNjPe58xdqon0 r1JES7klQeQDj9AfIhGzNnyo7KiLi4k9Mq48Cd2nttrX8XsG5Xj08tq2vWxucqY0Zf6W XEHw== X-Forwarded-Encrypted: i=1; AJvYcCUcMBsap2gfFQcOcM3iThsAuaoWlubpPXt+bu5LmDbbhXdugOW7YRwLJ9TcQotJvLN+0aUJn5V8vO70YCCe3czlbiDd05kSIXVI X-Gm-Message-State: AOJu0YwSGojH5TL44TgeHOaZ/+9fRVYbXaWscEyWya1QNFaGqTEI2Yiz lWR3x60tzwZauriKNtyFQainN5caANyOz24ysFStU4IXWyYBE7+MTKLm89WN0U+y7yrGZUJsPUs Bgu3zStV2WjGS8w8tgxZ2RyVbRxaigt6G6Pha X-Google-Smtp-Source: AGHT+IFz+DEnZJcEEaclJpEidk1Ybqz/Vxja1AciQfCSRQ7zO+sVw0Gb1IdH8lEuXEezw1JaEwHZxhm+cmpSShkuLsA= X-Received: by 2002:a17:902:d586:b0:1f4:97f5:d9d6 with SMTP id d9443c01a7336-1f6371b2251mr299435ad.3.1717111743237; Thu, 30 May 2024 16:29:03 -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: From: Evgenii Stepanov Date: Thu, 30 May 2024 16:28:51 -0700 Message-ID: Subject: Re: [PATCH] aarch64: Remove ld.so __tls_get_addr plt usage To: enh Cc: Florian Weimer , 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 , Kostya Serebryany , Dmitry Vyukov Content-Type: multipart/alternative; boundary="0000000000007f14d70619b43bda" X-Spam-Status: No, score=-16.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,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,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: --0000000000007f14d70619b43bda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 22, 2024 at 8:40=E2=80=AFAM enh wrote: > 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/i= nclude/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.) > This was meant to allow tool metadata cleanup for when a secondary thread exits, replacing the ugly PTHREAD_DESTRUCTOR_ITERATIONS hack, with a guarantee that no instrumented code will run on that thread after. It looks like the compiler-rt side was never implemented. I think our primary interest in this API was always in the dynamic tls hooks. > > > (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 > > > --0000000000007f14d70619b43bda--