From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13794 invoked by alias); 28 Oct 2009 12:29:52 -0000 Received: (qmail 13726 invoked by uid 48); 28 Oct 2009 12:29:41 -0000 Date: Wed, 28 Oct 2009 12:29:00 -0000 Message-ID: <20091028122941.13725.qmail@sourceware.org> From: "mjw at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20091023162529.10836.fche@redhat.com> References: <20091023162529.10836.fche@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug uprobes/10836] uprobes-provided pt_regs* are unreliable X-Bugzilla-Reason: AssignedTo 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: 2009-q4/txt/msg00326.txt.bz2 ------- Additional Comments From mjw at redhat dot com 2009-10-28 12:29 ------- This is also a problem for the dwarf based unwinder. In runtime/unwind.c we feed unwind_frame() a pt_regs struct describing the current state of the registers (plus some unwind tables, stp_module, etc.) Then that uses its internal unwind_state regs stack to keep track of what is going to happen with the pt_regs given the cfa ops found in the table. And when it is all processed it spits out a new pt_regs struct describing the state of one unwind step. In runtime/stack-.c we are feeding unwind_frame() initially the pt_regs given by either kprobes or uprobes (arch_unw_init_frame_info(&info, regs)). But the uprobes pt_regs are the "wrong kind" for user space although the do work most of the time. This could be fixed without having to change much by having the "loony concept" of synthesized pt_regs without having to change too much of this code. Otherwise we would need to make arch_unw_init_frame_info() smarter and detect we want the user space registers (which we know in stp_stack_print because tsk != NULL) and use the appropriate regsets to instantiate the unwind_info->regs. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10836 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.