From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6097 invoked by alias); 19 Dec 2014 15:21:02 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 6084 invoked by uid 89); 19 Dec 2014 15:21:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 19 Dec 2014 15:21:00 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBJFKwXE026689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 19 Dec 2014 10:20:59 -0500 Received: from fche.csb (vpn-60-95.rdu2.redhat.com [10.10.60.95]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBJFKw2b013061; Fri, 19 Dec 2014 10:20:58 -0500 Received: by fche.csb (Postfix, from userid 2569) id F262B5816E; Fri, 19 Dec 2014 10:20:45 -0500 (EST) To: Abe Jakop Cc: systemtap@sourceware.org Subject: Re: Systemtap Upcoming Feature: Address to File:Line Mapping References: <252539308.11641276.1418658500370.JavaMail.zimbra@redhat.com> <2066955740.484444.1418939520703.JavaMail.zimbra@redhat.com> From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 19 Dec 2014 15:21:00 -0000 In-Reply-To: <2066955740.484444.1418939520703.JavaMail.zimbra@redhat.com> (Abe Jakop's message of "Thu, 18 Dec 2014 16:52:00 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2014-q4/txt/msg00240.txt.bz2 ajakop wrote: > [...] > I have been working on a new feature for SystemTap to provide > address to file:line mappings. [...] Nice, I can hardly wait. > [...] As for using this new feature, there are two new tapset > functions, usymfileline() and symfileline(). The former requires a > user-space address, and a kernel address for the the latter. Could we also have [u]symfile and/or [u]symline? That way, script code wouldn't need to parse [u]symfileline if they only wanted one or the other. > Since this feature stores line data for runtime access, > using this feature may result in large probe modules. Looking forward to advice as to whether further data compression may significantly help. > [...] > linenumbers.stp > =============== > 1 probe process.statement("*") { > 2 printf("addr: %#x, file and line: %s\n", > 3 addr(), usymfileline(addr()) ) > 4 } (uaddr() in this case.) > Running the script from above, this is the output. > > $ stap linenumbers.stp -c ./linenumbers > addr: 0x400544, file and line: linenumbers1.c:13 > addr: 0x400517, file and line: linenumbers1.c:7 > [...] So to that extent, it's kind of like decomposing pn(), which should have the function / line number stuff expanded from the statement("*") wildcard. Another way this could be used is a more detailed version of the pf3.stp sample, logging [u]symfileline in addition to the other stuff. Glancing at that pf3.stp sample, maybe [u]sym* family of functions should more regularly throw catchable errors in case of errors, instead of hard-coding a policy of returning a hexified parameter. That way the caller can more easily omit the info in its report. So, before: try { // modname() can throw fn = "k:".modname(addr()).":".symname(addr()).":".symfileline(addr()) } catch { fn = "k::".symname(addr()).":".symfileline(addr()) } after: try { part_1 = "k:".modname(addr()) } catch { part_1 = sprintf("k:%p",addr()) } try { part_2 = ":".symname(addr()) } catch { part_2 = "" } try { part_3 = ":".symfileline(addr()) } catch { part3 = "" } fn = part_1.part_2.part_3 It's a little wordier, but limits noise from unavailable information. Hm, what if we had an expression-context try/catch? (Maybe a generalization of ? : ... sort of like @choose_defined()?) part_1 = "k:" . try_catch(modname(addr()), sprintf("%p",addr())) part_2 = try_catch(":".symname(addr()), "") part_3 = try_catch(":".symfilename(addr()), "") fn = part_1.part_2.part_3 - FChE