From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15981 invoked by alias); 23 Jul 2012 09:35:33 -0000 Received: (qmail 15841 invoked by uid 22791); 23 Jul 2012 09:35:32 -0000 X-SWARE-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e34.co.us.ibm.com (HELO e34.co.us.ibm.com) (32.97.110.152) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jul 2012 09:35:16 +0000 Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 23 Jul 2012 03:35:14 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e34.co.us.ibm.com (192.168.1.134) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 23 Jul 2012 03:34:35 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 15F113E40039 for ; Mon, 23 Jul 2012 09:34:34 +0000 (WET) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6N9YYcx260000 for ; Mon, 23 Jul 2012 03:34:34 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6N9YX7v023029 for ; Mon, 23 Jul 2012 03:34:34 -0600 Received: from linux.vnet.ibm.com ([9.124.158.28]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q6N9YV4v022962; Mon, 23 Jul 2012 03:34:32 -0600 Date: Mon, 23 Jul 2012 09:35:00 -0000 From: Srikar Dronamraju To: Mark Wielaard Cc: Frank Ch Eigler , systemtap@sourceware.org Subject: Re: [Bug runtime/14026] inode based uprobes print_ubacktrace doesn't resolve the symbol name Message-ID: <20120723093430.GC4874@linux.vnet.ibm.com> Reply-To: Srikar Dronamraju References: <20120723055706.GB4874@linux.vnet.ibm.com> <1343031967.30850.28.camel@springer.wildebeest.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <1343031967.30850.28.camel@springer.wildebeest.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12072309-1780-0000-0000-000007A4AF3D X-IBM-ISS-SpamDetectors: X-IBM-ISS-DetailInfo: BY=3.00000288; HX=3.00000193; KW=3.00000007; PH=3.00000001; SC=3.00000004; SDB=6.00159055; UDB=6.00035907; UTC=2012-07-23 09:35:10 X-IsSubscribed: yes 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 X-SW-Source: 2012-q3/txt/msg00075.txt.bz2 * Mark Wielaard [2012-07-23 10:26:07]: > On Mon, 2012-07-23 at 11:27 +0530, Srikar Dronamraju wrote: > > > --- Comment #24 from Frank Ch. Eigler 2012-07-19 14:53:23 UTC --- > > > This inode-uprobes shortcoming is biting other users too. Perhaps we can work > > > around it in stap land by using the mmap callbacks that check build-ids to also > > > go and calculate run-time virtual addresses of the inode-uprobes, so they can > > > be filled in around probe execution time. > > > > > > > Can you please elaborate on whats the shortcoming? > > The issue is that probe handlers (and various parts of the systemtap > runtime) assume they have access to the exact REG_IP where the program > was probed. At least on x86 architectures there is an off-by-one because > the IP is increased before the probe handler is called. This results in > the probe handler (and unwinder) not knowing exactly where they are. In > some cases that leads to errors since the IP spilled over into the next > function (in which case the runtime cannot find the correct CFI). > > With kprobes and utrace-uprobes tapsets.cxx works around this by doing > the following: > > // Make it look like the IP is set as it would in the actual user > // task when calling real probe handler. Reset IP regs on return, so > // we don't confuse uprobes. PR10458 > s.op->newline() << "{"; > s.op->indent(1); > s.op->newline() << "unsigned long uprobes_ip = REG_IP(c->uregs);"; > s.op->newline() << "SET_REG_IP(regs, inst->vaddr);"; > s.op->newline() << "(*sups->probe->ph) (c);"; > s.op->newline() << "SET_REG_IP(regs, uprobes_ip);"; > s.op->newline(-1) << "}"; > > We need something similar for inode-uprobes, because currently it has: > > // XXX: Can't set SET_REG_IP; we don't actually know the relocated address. > // ... In some error cases, uprobes itself calls uprobes_get_bkpt_addr(). > uprobes_get_bkpt_addr() [ which is now called uprobe_get_swbp_addr ] will only return the virtual address where a probe is placed (which is probably what you are looking for). uprobe_get_swbp_addr() never sets/resets IP. However its not a static function but its not exported too. The other option would be have something similar to uprobe_get_swbp_addr() within stap. Including uprobes.h would necessarily mean that UPROBE_SWBP_INSN_SIZE is always set. But it means we have to depend on UPROBE_SWBP_INSN_SIZE. May the later option is not all that nice. -- Thanks and regards Srikar