[PATCH] aarch64: Remove ld.so __tls_get_addr plt usage

[Evgenii Stepanov]

On Wed, May 22, 2024 at 8:40 AM enh <enh@google.com> wrote:

> On Mon, Apr 15, 2024 at 7:41 AM Florian Weimer <fweimer@redhat.com> 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.)
>

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240530/b05215e5/attachment.htm>