Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.