From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16263 invoked by alias); 29 Jan 2014 18:50:44 -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 16216 invoked by uid 48); 29 Jan 2014 18:50:40 -0000 From: "earthdok at google 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:50: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: earthdok at google 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/msg00370.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16291 --- Comment #26 from Sergey Matveev --- >> Is there a reason you're not simply using pthread_create to create this thread? The task must belong to a different process group, because ptrace cannot attach to tasks within the same process group. We also cannot use a full-blown separate process for this because we need direct access to the parent's address space. Even if we could ptrace between threads, it still wouldn't be safe to call glibc functions while other threads are frozen at arbitrary points. >> 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. Right, the difference is that for functions like __libc_get_stack_bounds(), we don't have to call them during the "stop-the-world" phase. We can query the stack bounds once (immediately after the thread is created) and store them in our own thread registry, which we can safely access from the cloned task later. We cannot reliably do this to DTLS with the "iterator" interface you proposed. If we queried this information at some point prior to freezing the threads, we would have no way of knowing that it's not gone out of date by the time we actually freeze them. -- You are receiving this mail because: You are on the CC list for the bug.