From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8913 invoked by alias); 29 Jan 2014 18:35:55 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 8857 invoked by uid 48); 29 Jan 2014 18:35:52 -0000 From: "konstantin.s.serebryany at gmail dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries Date: Wed, 29 Jan 2014 18:35:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.19 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: konstantin.s.serebryany at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 2.20 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg00369.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16291 --- Comment #25 from Kostya Serebryany --- (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.