[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <871rpwso5s.fsf@mid.deneb.enyo.de>
Date: Fri, 13 Mar 2020 08:35:11 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: enh <enh@...gle.com>
Cc: Szabolcs Nagy <szabolcs.nagy@....com>, libc-coord@...ts.openwall.com, nd@....com
Subject: Re: https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
* enh:
> interestingly, i was made aware of some prior art...
>
> API: https://fuchsia.googlesource.com/fuchsia/+/master/zircon/third_party/ulib/musl/include/zircon/sanitizer.h
>
> lsan usage: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/lsan/lsan_common_fuchsia.cpp
I think this is different because the Fuchsia build uses a vendored
LLVM, right?
So changing that interface would be quite easy, and it doesn't span
multiple GCC, LLVM versions and different libcs.
>>> The callbacks could also over-constrain the implementation. It's hard
>>> to predict the future, but one aspect is that the static TLS
>>> boundaries are not actually fixed by the ABI. You cannot move the TLS
>>> data, but you can grow the area in one direction.
>
> this is one reason why i'm not even sure it makes much sense to try to
> have _an_ API.
More introspection for TLS data is definitely something that some
people need. However, an API only works if you can run code, so it
only fits a subset of the requirements.
A lot of complexity in our TLS implementation comes from lazy
allocation of TLS data. If we determine that we do not actually need
that (perhaps after adding thread-local destructors), then it might
become easier to define some sort of interface because it will be
easier to describe in a declarative fashion what the data structures
look like.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
