From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14463 invoked by alias); 24 Jan 2014 19:10:52 -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 14406 invoked by uid 48); 24 Jan 2014 19:10:46 -0000 From: "jlebon at redhat dot com" To: systemtap@sourceware.org Subject: [Bug translator/1133] support .callees probe pattern extension Date: Fri, 24 Jan 2014 19:10:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: translator X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jlebon at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: week X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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-q1/txt/msg00064.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=1133 Jonathan Lebon changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jlebon at redhat dot com --- Comment #4 from Jonathan Lebon --- Unfortunately, it seems like the new DWARF extensions added by GCC don't allow us (at least for now) to support a .callsites probe because there is no attribute from which we can retrieve the address of the call site. Although the DWARF issue[1] mentions a DW_TAG_call_site attribute for it (DW_AT_call_site_pc), this hasn't been implemented in GCC[2]. If/when it is implemented, then we could add a syntax along those lines. GCC does set the DW_AT_low_pc attribute of DW_TAG_call_site, but it seems like it points to the instruction after the call site (at first I thought it was the return addr, but it points to the next addr even when it's a tail call). What the new DW_TAG_call_site DIE does give us however is a way of listing callees of a DW_TAG_subprogram. So, we could use them to support .callees("") by retrieving the address from the DIEs of all target functions. Note however that call site DIEs are not guaranteed to be emitted for all call sites (DW_TAG_subprogram attributes such as DW_AT_all_call_sites could be examined to determine if they're all there, if it matters to us). Also note that call site DIEs are not emitted when optimization is turned off. BTW, for those looking for more details in the reasoning behind the addition of DW_TAG_call_site, see the excellent paper[3]. [1] DWARF issue for DW_TAG_call_site http://www.dwarfstd.org/ShowIssue.php?issue=100909.2 [2] GCC patch adding support for DW_TAG_call_site and DW_OP_entry_value http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00814.html [3] Improving debug info for optimized away parameters http://gcc.gnu.org/wiki/summit2010?action=AttachFile&do=get&target=jelinek.pdf [4] DWARF issue for DW_OP_entry_value http://www.dwarfstd.org/ShowIssue.php?issue=100909.1 -- You are receiving this mail because: You are the assignee for the bug.