Date: Fri, 6 Mar 2020 10:13:52 -0800 From: enh <enh@...gle.com> To: Szabolcs Nagy <szabolcs.nagy@....com> Cc: libc-coord@...ts.openwall.com, Florian Weimer <fw@...eb.enyo.de>, nd@....com Subject: Re: https://sourceware.org/glibc/wiki/ThreadPropertiesAPI 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 On Fri, Mar 6, 2020 at 6:09 AM Szabolcs Nagy <szabolcs.nagy@....com> wrote: > > 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. this is one reason why i'm not even sure it makes much sense to try to have _an_ API. > > 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.