From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18888 invoked by alias); 27 Oct 2009 12:27:26 -0000 Received: (qmail 18852 invoked by uid 48); 27 Oct 2009 12:27:12 -0000 Date: Tue, 27 Oct 2009 12:27:00 -0000 Message-ID: <20091027122712.18851.qmail@sourceware.org> From: "fche 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/msg00302.txt.bz2 ------- Additional Comments From fche at redhat dot com 2009-10-27 12:27 ------- (In reply to comment #1) > > Several registers appearing in a utrace-oriented pt_regs do not accurately > > represent the state of the user-space task. > > Is this concern about instruction pointer pointing past the breakpoint? No, not only. > or do we have additional concerns? If yes do we have specific registers in mind? It depends. Sometimes esp, sometimes ebp, and I think I've seen other registers with inconsistent values too. Compare a systemtap print_regs with a gdb breakpoint "info regs" at the same spot. > uprobes passes the pt_regs it gets from utrace's report_signal callback as is to > the handler. Yes. Unfortunately, these registers do not completely & correctly match the state of the user-space thread. > This bug refers to two other bugs which point to problems in user space markers. > So is this problem only seen on user space markers? or can we see this problem > on plain uprobes probe points too. In this context, user-space markers are a special case of uprobes. Statement uprobes (bypassing prologue heuristics) at the function entry point also display this problem. > Is there any reason why this synthesis should be done at the uprobes end and not > at the client end? I believe I summarized some pros & cons already. Hiding the regset stuff from uprobes clients would be the main benefit. Perhaps the run-time costs of doing this could be controlled by a struct-uprobes flag that tells uprobes whether the client is interested in raw pt_regs, nothing, or regset-filled pt_regs. > Do you see all uprobe clients facing this problem? Yes. > If its a problem faced by all uprobe clients, then is it worth checking if > utrace should send the synthesized pt_regs as a parameter to report_signal. Roland? -- 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.