From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3045 invoked by alias); 31 Jan 2014 05:31:05 -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 2985 invoked by uid 48); 31 Jan 2014 05:31:01 -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 05:31: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/msg00406.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16291 --- Comment #33 from Carlos O'Donell --- (In reply to Kostya Serebryany from comment #32) > > Instead of a callback could we use a systemtap probe with the right > > arguments? We have precedent set for adding probes to libc and it would be > > easy to do with the current infrastructure and low-overhead. > > I admit I have not investigated systemtap properly (need to install a newer > Linux distro first). However, from what I see systemtap is not enabled by > default > in glibc build and requires extra packages to be installed on the system. > Which means that some lsan/msan users will be left behind > (those who can't install extra packages) and we'll be forced to keep the hack > for the fallback, which defeats the purpose of having the right solution. For RHEL and Fedora we always enable systemtap. It is a requirement that the users kernel have kprobes enabled. The reason I mention systemtap is that it gives you a richer and more flexible way to look at the internals of glibc in realtime. > Besides there is a consistency reason (which is not necessary relevant for > you). > Sanitizers already heavily rely on interposition for many cases, > including all cases where glibc has systemtap hooks, but not limited to that. That's fine, and you can continue to user interposition. I'm not saying you shouldn't. I'm just saying that for TLS and stack extents we may wish to create a probe point that we declare stable for tool usage. > Even if we used systemtap for pthread events, at least one hook > is not usable for us (in pthread_create, we actually replace one of the > parameters, which systemtap does not allow, afaict). systemtap allows modifying all parameters and having those modifications impact the running application. In fact I use systemtap all the time to inject failures into glibc code in realtime for testing. I hope that I don't sound like I'm telling to use systemtap. Far from it. I'm just suggesting an option, and trying to figure out if this option is or is not a good match for what you want. In summary: - Needs kprobes. - Deep introspection with internal glibc probe points. - Ability to modify arguments. The in-process function call is probably still faster... -- You are receiving this mail because: You are on the CC list for the bug.