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 <>
To: enh <>
Cc: Szabolcs Nagy <>,,
Subject: Re:

* enh:

> interestingly, i was made aware of some prior art...
> API:
> lsan usage:

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.