[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Mar 2020 14:09:24 +0000
From: Szabolcs Nagy <szabolcs.nagy@....com>
To: libc-coord@...ts.openwall.com, Florian Weimer <fw@...eb.enyo.de>,
enh <enh@...gle.com>
Cc: nd@....com
Subject: Re:
https://sourceware.org/glibc/wiki/ThreadPropertiesAPI
On 06/03/2020 09:05, Florian Weimer wrote:
> * 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.
yes, to me it was unclear why is it a 'dynamic tls allocation'
callback and not just an 'as-safe allocation' callback.
the libc may not need as-safe allocation for dynamic tls and
dynamic tls may be allocated together with lot of other stuff
(e.g. stack and tls for currently loaded dsos can be allocated
together at thread creation time, or dso related bookkeeping
and tls for current threads can be allocated together at dlopen
time)
if there is a semantic distinction between normal allocations
and dynamic tls then it likely needs more info (e.g. tls for
specific thread+dso or boundaries per tls variable).
>
> 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.
i think running callbacks while signals are blocked
and the thread is no longer in a state where user
code should run is a bit tricky to specify.
but i see that it can be useful.
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.
