Re: support for BookE hardware debug features

Joel Brobecker
2009-03-02T20:55:29Z

> - 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 <litteral>
(gdb) watch <variable> if <variable> BINOP_EQUAL <litteral>

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 <litteral>", 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