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.