From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23276 invoked by alias); 6 May 2012 19:39:13 -0000 Received: (qmail 23267 invoked by uid 22791); 6 May 2012 19:39:12 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_MJ X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 06 May 2012 19:39:00 +0000 From: "mjw at redhat dot com" To: systemtap@sourceware.org Subject: [Bug runtime/14026] print_ubacktrace doesn't resolve the symbol name Date: Sun, 06 May 2012 19:39:00 -0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: systemtap X-Bugzilla-Component: runtime X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mjw at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: systemtap at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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-q2/txt/msg00128.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=14026 --- Comment #19 from Mark Wielaard 2012-05-06 19:38:42 UTC --- I finally understand what is happening, though I still don't understand how it can happen. The real problem is that we enter the unwinder with PC 8074811. While the probe point actually is 8074810. This is normally caused because when a breakpoint is taken the x86 increases the PC by one before invoking the interrupt handler. But in the uprobe handler we already take care of this: // 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) << "}"; In the case of GCC-4.4 the FDE has its first DW_CFA_advance_loc 1. So we think we need to process the instructions between 8074810 and 8074811. While with GCC-4.6 the FDE has its first DW_CFA_advance_loc 4, so the one-off in the PC address doesn't matter and we don't process extra FDE instructions. The question is why doesn't the above trick of adjusting the IP to compensate for the breakpoint PC increase work? To check whether this is the real issue, you can try this patch: diff --git a/runtime/stack-dwarf.c b/runtime/stack-dwarf.c index 9c55997..fbea35c 100644 --- a/runtime/stack-dwarf.c +++ b/runtime/stack-dwarf.c @@ -69,6 +69,7 @@ static void __stp_dwarf_stack_user_print(struct pt_regs *regs, int verbose, { struct unwind_frame_info *info = &uwcontext->info; arch_unw_init_frame_info(info, regs, ! uregs_valid); + info->call_frame = 1; /* XXX Always assume PC is off by one. */ while (levels) { int ret = unwind(uwcontext, 1); -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.