This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #21 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
(In reply to Rich Felker from comment #20)
> I'm not convinced that __libc_on_dynamic_tls_create and
> __libc_on_dynamic_tls_destroy are a good API. Assuming they're called when
> the thread obtains new TLS storage, the implementations of these functions
> would need to be both thread-safe and AS-safe. This requirement would at
> least need to be documented.

Good point. thread- and AS- safe implementation is clearly possible. 

> 
> A cleaner API alternative might be to provide an iterator for TLS memory
> ranges in the current thread, similar to how dl_iterate_phdr works for
> loaded DSOs. This would avoid placing complex safety requirements on the
> component using the API and would avoid having global state. (

I am not sure this will work for us. 
Consider LeakSanitizer, which stops all threads before starting real work.
It needs to query all threads while they are stopped, so it can not ask 
the threads to iterate over their TLS ranges, the information should
be stored somewhere already. 

> Interposing
> symbols over top of libc-internal symbols is a NASTY hidden global state,
> since it admits only one client to the API.)
Instead of interposing we can use callbacks

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]