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.