[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries

["konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16291

--- Comment #42 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
> Kostya, can you please start a design page for the API on the glibc wiki?
> https://sourceware.org/glibc/wiki/
Will do as soon as the site stops throwing me out with timeouts. :( 


(In reply to Rich Felker from comment #39)
> I don't like hook-style callbacks either. My preference remains a
> query-based API, preferably documented as being AS-safe and possibly other
> properties that would make ASAN and similar tools happy (for example having
> bounded execution time even if other threads are stopped indefinitely such
> as via a signal handler interrupting them while holding a lock). I realize
> this makes a bit more work for tools like ASAN which would rather have
> asynchronous notification (note: they could still get it by intercepting the
> functions that could change the state then calling the query function during
> the intercept), but such tools are already doing something that's fairly
> hard and invasive.

We need to be notified about both creation and destruction of dynamic tls.
It is reasonably simple to get notification of DTLS creation:
  intercept __tls_get_addr and check that we observe the DSO id for the first
time. Still a bit hackish. Besides, if we still rely on the interceptor for
__tls_get_addr to call the query function, it means that we introduce
noticeable slowdown for all DTLS accesses. 
But how do I get notified about DTLS destruction? 


(In reply to Sergey Matveev from comment #41)
> Doesn't this basically translate to __dl_tls_getaddr(), as far as allocation
> of new DTLS blocks is concerned? It's the only function that we can

Sergey, do you mean __tls_get_addr? 
Yes, intercepting all calls to __tls_get_addr just to catch the first moment
of DTLS creation is costly and it does not solve the problem of intercepting 
DTLS destruction

> intercept, and it's a hot one. If we take this approach, we'll need a fast
> way to check whether our record needs updating before performing a full
> query. Something as simple as a function which returns the current DTV's
> generation counter should work, I think?
There is a simpler way: store a fixed size bit vector in static TLS, 
i-th bit indicating whether __tls_get_addr has been called with the 
i-th DSO.

-- 
You are receiving this mail because:
You are on the CC list for the bug.