This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- From: "konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 29 Jan 2014 10:40:31 +0000
- Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- Auto-submitted: auto-generated
- References: <bug-16291-131 at http dot sourceware dot org/bugzilla/>
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.