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.