[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
