[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 06 Mar 2020 10:05:22 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: enh <enh@...gle.com>
Cc: libc-coord@...ts.openwall.com
Subject: Re: https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
* enh:
> is anyone else looking at implementing
> https://sourceware.org/glibc/wiki/ThreadPropertiesAPI ? we're starting
> to look at this for Android now, and i was wondering whether anyone
> had any implementation experience.
I've been discussing TLS-related issues with quite a few people
recently. Lack of transparency when it comes to TLS layout is one
aspect.
I must say I do not particularly like the proposed callbacks (which
are not implemented in glibc). Conceptually, an audit module
(LD_AUDIT or DT_AUDIT) would be a better fit. With an audit module,
it's probably easier to avoid some of the strange loops inherent to
such low-level callbacks, although what code can do from them will
always be severely limited.
The callbacks do not look expressive enough for tools like valgrind
that might benefit from knowing the boundaries between TLS variables.
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.
I forgot that the “Callback for thread exit” aspect of the proposal,
otherwise I would referenced it in my TLS initarray message. I would
expect this to be quite widely used, by different libraries. With the
proposal, people would have to remember to chain callbacks using
RTLD_NEXT, which is neither clean nor efficient.
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.
