From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25521 invoked by alias); 3 Mar 2009 19:32:25 -0000 Received: (qmail 25511 invoked by uid 22791); 3 Mar 2009 19:32:24 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e24smtp02.br.ibm.com (HELO e24smtp02.br.ibm.com) (32.104.18.86) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Mar 2009 19:32:18 +0000 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by e24smtp02.br.ibm.com (8.13.1/8.13.1) with ESMTP id n23JhkF5031321 for ; Tue, 3 Mar 2009 16:43:46 -0300 Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n23KVbFV3862568 for ; Tue, 3 Mar 2009 17:31:37 -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 n23JWD6Q027288 for ; Tue, 3 Mar 2009 16:32:13 -0300 Received: from [9.18.200.51] ([9.18.200.51]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n23JWC3r027270; Tue, 3 Mar 2009 16:32:12 -0300 Subject: Re: support for BookE hardware debug features From: Thiago Jung Bauermann To: Joel Brobecker Cc: gdb ml , Luis Machado , =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= In-Reply-To: <20090302205516.GF3632@adacore.com> References: <1236026362.8949.96.camel@localhost.localdomain> <20090302205516.GF3632@adacore.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 03 Mar 2009 19:32:00 -0000 Message-Id: <1236108731.30573.58.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-03/txt/msg00026.txt.bz2 El lun, 02-03-2009 a las 12:55 -0800, Joel Brobecker escribió: > > - support for the two DVCs (Data Value Compare), which enable > > hardware-accelerated conditions for hardware watchpoints, > > This sounds like an interesting feature. Certain versions of VxWorks > now come with a feature that's slightly comparable. I don't believe > that the target really had DVC, but the kernel made it look that way. > The purpose is to avoid having a lot of communication between the > debugger and the target when the hardware value check is a simple 32bit > value compare. Nice to know that there are other targets with a similar feature. > > We don't know yet how we'll extend gdb commands to express the ranged > > breakpoints and watchpoints, and the DVCs. For the latter maybe we can > > add some intelligence to use the registers if the condition expression > > is simple enough, I didn't think much about this yet. > > When I looked at extending GDB for this, the feedback I got from the > users is that they didn't want to have a special syntax to activate > the feature. So I had to hack into condition evaluation code to > add a target-specific feature that would inspect the expression tree > and identify simple cases where DVC could be used. > > It wasn't all that pretty, but it remained a reasonable approach > because we restricted ourselves to a selected number of expressions: > > (gdb) watch *
if *
BINOP_EQUAL > (gdb) watch if BINOP_EQUAL > > For illustration, I fished the code out from one of our old trees. > I'm not sure whether this is really a viable approach for you or not. > The thing is, I don't see any other except maybe formalizing a little > bit more how DVC would work and push some of the tree-inspection code > up in the core. I was thinking about something along those lines too. Possibly adding a target hook which would receive a struct expression with the condition and a watchpoint address, and return true if it can be hardware-accelerated. That hook would also set up the hardware debug registers accordingly. Since there is at least one other target (VxWorks, as you say) which would also benefit from the hook, this seems to be a good option, what do you think? Regarding what is a viable approach, our main concern is that we do it in a way which will be accepted upstream. > static int > watch_star_address_if_star_address_equal_literal_p (struct breakpoint *b, > TGT_ARG_T *data_value) Thanks for sharing this code, by the way. Just a question to be on the safe side: is there any copyright implication if we stare at it for too long (half-joking)? -- []'s Thiago Jung Bauermann IBM Linux Technology Center