From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3938 invoked by alias); 14 May 2008 17:31:52 -0000 Received: (qmail 3919 invoked by uid 22791); 14 May 2008 17:31:49 -0000 X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 May 2008 17:31:27 +0000 Received: from mailhub3.br.ibm.com (unknown [9.18.232.110]) by igw3.br.ibm.com (Postfix) with ESMTP id 488213900F0 for ; Wed, 14 May 2008 14:16:43 -0300 (BRST) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4EHVNqP512244 for ; Wed, 14 May 2008 14:31:23 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4EHVG1m012919 for ; Wed, 14 May 2008 14:31:16 -0300 Received: from [9.18.238.95] ([9.18.238.95]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4EHVGtZ012726; Wed, 14 May 2008 14:31:16 -0300 Subject: Re: [RFC] initial support for watchpoints in frysk From: Thiago Jung Bauermann To: Phil Muldoon Cc: frysk ml In-Reply-To: <482A999F.7030107@redhat.com> References: <1210733704.617.55.camel@localhost.localdomain> <482A999F.7030107@redhat.com> Content-Type: text/plain Date: Thu, 15 May 2008 04:07:00 -0000 Message-Id: <1210786270.617.75.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00076.txt.bz2 Hi Phil, Thanks for your comments. On Wed, 2008-05-14 at 08:49 +0100, Phil Muldoon wrote: > The watchpoint specific code looks ok. I just added an alignment check > yesterday to x86 and x8664, so if this is important to PPC then should > add the check too. Yes, I saw that and put the same in powerpc. Thanks for the heads up. > I'm a bit worried about the live.LinuxPtraceTask setDebugReg and > getDebugReg. This is a PPC specific function but it is in a non-ISA > class. So I think it would lead to confusion. If you were to call this > on x86 and x8664 what would happen? Right, I just found out that powerpc is the only Linux arch with PTRACE_SET_DEBUGREG... > Access to the x86 and x8664 debug status registers are performed as follows: > > return task.getRegister(X8664Registers.DEBUG_STATUS); > > I think this call eventually resolves to > RegisterBanks.getBankArrayRegister() which again resolves into ISA > specific methods to get the register. Andrew who did the register code > would know better here. I can create a debugregs() method in the frysk.sys.ptrace.RegisterSet class (or in a subclass, perhaps?) and then use the RegisterSetByteBuffer to use the infrastructure you mention. It's a somehwat involved solution for just one register, but it does fit better the Frysk registers framework. > On x86/x8664 we can just look at the bits in the debug status register > when a stop event/sigtrap has arrived to see if it is a watchpoint > event. If you look at the handleTrappedEvent in the Running and the > Stepping states you can see there is a very specific sequence of checks > here. I'm guessing this won't work on the PPC then as you need to > examine the siginfo structure. I just looked at Running.checkWatchpoint (I believe that is what you are referring to) and it will work fine for powerpc. The siginfo check would take place inside WatchpointFunctions.hasWatchpointTriggered method, so it's encapsulated. I just need checkWatchpoint to pass the Signal object to it (and also, I need the object to have the siginfo information). > What data are you looking for in there? I need to examine siginfo.si_code to verify that it's a trap originated from a hardware watchpoint. I can also look at siginfo.si_addr to get the exact address which triggered it (since the watchpoint looks at an 8 byte range). > > If my understanding is correct, this would make the siginfo available to > > LinuxPtraceTaskState.Running.handleStoppedEvent, > > Should that be LinuxPtraceTaskState.Running.handleTrappedEvent and > LinuxPtraceTaskState.Stepping.handleTrappedEvent? These two states right > now are the only states that handle watchpoints. (ie sigtrap occurs, > check if it is a watchpoint, if not, pass the sigtrap along). Right, my mistake. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center