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 #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.


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