From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32424 invoked by alias); 2 Mar 2009 20:55:29 -0000 Received: (qmail 32415 invoked by uid 22791); 2 Mar 2009 20:55:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Mar 2009 20:55:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C7F192BAB71; Mon, 2 Mar 2009 15:55:21 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xx1w+egS3c81; Mon, 2 Mar 2009 15:55:21 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 5B5B92BAB3F; Mon, 2 Mar 2009 15:55:21 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 50DB2E7ACD; Mon, 2 Mar 2009 12:55:16 -0800 (PST) Date: Mon, 02 Mar 2009 20:55:00 -0000 From: Joel Brobecker To: Thiago Jung Bauermann Cc: gdb ml , Luis Machado , =?iso-8859-1?Q?S=E9rgio_Durigan_J=FAnior?= Subject: Re: support for BookE hardware debug features Message-ID: <20090302205516.GF3632@adacore.com> References: <1236026362.8949.96.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1236026362.8949.96.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.2i 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/msg00008.txt.bz2 > - 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. > - two ranged hardware breakpoints, > - one ranged hardware watchpoint. Looking forward to these two as well. > 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. static int watch_star_address_if_star_address_equal_literal_p (struct breakpoint *b, TGT_ARG_T *data_value) { CORE_ADDR exp_address; CORE_ADDR cond_address; /* First, check the watchpoint location expression. It should be of the form "*
". Check that the associated tree corresponds to that expression, that is 5 elements, first a UNOP_IND, and then an OP_LONG. */ if (b->exp->nelts != 5 || b->exp->elts[0].opcode != UNOP_IND || b->exp->elts[1].opcode != OP_LONG) { watchpoint_debug ("Location is not *
"); return 0; } exp_address = b->exp->elts[3].longconst; /* Next, check the watchpoint condition expression. It should be of the form "*
EQUAL ", where EQUAL is the equality binary operator. The associated tree should have exactly 10 elements in it, all in a very specific order. */ if (b->cond->nelts != 10 || b->cond->elts[0].opcode != BINOP_EQUAL || b->cond->elts[1].opcode != UNOP_IND || b->cond->elts[2].opcode != OP_LONG || b->cond->elts[6].opcode != OP_LONG) { watchpoint_debug ("Condition is not *
EQUAL "); return 0; } cond_address = b->cond->elts[4].longconst; /* Make sure that the two addresses are the same. */ if (exp_address != cond_address) { watchpoint_debug ("Addresses in location and condition are different"); return 0; } /* At this point, all verifications were positive, so we can use hardware-assisted data-matching. Set the data value, and return non-zero. */ *data_value = b->cond->elts[8].longconst; return 1; -- Joel