From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 789 invoked by alias); 31 Jan 2014 20:43:24 -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 722 invoked by uid 48); 31 Jan 2014 20:43:20 -0000 From: "carlos at redhat dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries Date: Fri, 31 Jan 2014 20:43: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: carlos at redhat 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/msg00419.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16291 --- Comment #40 from Carlos O'Donell --- (In reply to Rich Felker from comment #39) > I don't like hook-style callbacks either. My preference remains a > query-based API, preferably documented as being AS-safe and possibly other > properties that would make ASAN and similar tools happy (for example having > bounded execution time even if other threads are stopped indefinitely such > as via a signal handler interrupting them while holding a lock). I realize > this makes a bit more work for tools like ASAN which would rather have > asynchronous notification (note: they could still get it by intercepting the > functions that could change the state then calling the query function during > the intercept), but such tools are already doing something that's fairly > hard and invasive. I agree with you. I'd rather have us discuss a non-callback API first and see if we can come up with something. > So far I've been looking at this tracker thread so far with the hopes of > being able to provide the same or close-to-the-same API in musl, but if it > looks like that's not likely to happen or it's distracting from the goal of > getting something done with respect to just glibc, I can back off somewhat > from this thread, focusing any further contribution I make to it on just > technical aspects. That's fine. We have other libc's to consider also including bionic, uclibc, etc. Which might need to implement this API. -- You are receiving this mail because: You are on the CC list for the bug.