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 18:35:51 +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 #25 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
(In reply to Rich Felker from comment #24)
> What about an enumeration API that takes a target pthread_t rather than
> operating on the calling thread?
Equally dislike.
MemorySanitizer needs the information on the TLS creation/destruction
event when it happens to avoid false positives. (comment #16)
> This is just an idea; I'm not sure I like
> it either, because it's inherently racy (the information returned may be
> outdated) unless you call it with the target thread stopped or at least
> blocked. I also think it may be unsafe to call it from a "thread" created
> with raw clone, but this really applies to ANY libc function (even the
> others we're proposing); all libc functions are free to assume they have a
> valid thread pointer, TCB, TLS, DTV, etc. which LeakSanitizer cannot provide
> without poking badly at glibc internals.
> Is there a reason you're not simply
> using pthread_create to create this thread? The POSIX threads API is
> intended to be such that applications should not need to know or care about
> the existence of threads produced internally by the implementation or by
> third-party library functions.
Sergey, please reply here, you are better equipped.
--
You are receiving this mail because:
You are on the CC list for the bug.