From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3173 invoked by alias); 14 May 2008 07:50:21 -0000 Received: (qmail 3165 invoked by uid 22791); 14 May 2008 07:50:21 -0000 X-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 May 2008 07:49:59 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m4E7ntuR023521; Wed, 14 May 2008 03:49:55 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m4E7nt48004693; Wed, 14 May 2008 03:49:55 -0400 Received: from localhost.localdomain (vpn-14-103.rdu.redhat.com [10.11.14.103]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m4E7nqZG013282; Wed, 14 May 2008 03:49:53 -0400 Message-ID: <482A999F.7030107@redhat.com> Date: Wed, 14 May 2008 17:31:00 -0000 From: Phil Muldoon User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Thiago Jung Bauermann CC: frysk ml Subject: Re: [RFC] initial support for watchpoints in frysk References: <1210733704.617.55.camel@localhost.localdomain> In-Reply-To: <1210733704.617.55.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 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/msg00075.txt.bz2 Thiago Jung Bauermann wrote: > Hi, > Hi Thiago, > Since fhpd is complaining rather loudly about not supporting watchpoints > in Power, I decided to add such support. :-) > > I'd like to ask your opinion, especially regarding two > methods I had to add to frysk.sys.Ptrace and > frysk.proc.live.LinuxPtraceTask: setDebugReg and getDebugReg. They are > necessary because on the PowerPC architecture, debug registers are a > priviledged resource, and userland need to access them via > PTRACE_SET_DEBUGREG and PTRACE_GET_DEBUGREG. What do you think, are > these changes ok? > 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. 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? 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. > Now regarding why the patch doesn't work: in order to verify if the > process stopped because of the hardware watchpoint, I need to examine > the siginfo structure which comes with the SIGTRAP. This information is > not available to Frysk yet, so I'd like your opinion on the following > approach: > > 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. What data are you looking for in there? > 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). Regards Phil