This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: support for BookE hardware debug features
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb ml <gdb at sourceware dot org>, Luis Machado <luisgpm at linux dot vnet dot ibm dot com>, Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>
- Date: Mon, 2 Mar 2009 12:55:16 -0800
- Subject: Re: support for BookE hardware debug features
- References: <1236026362.8949.96.camel@localhost.localdomain>
> - 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 *<address> if *<address> 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 "*<address>". 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 *<address>");
return 0;
}
exp_address = b->exp->elts[3].longconst;
/* Next, check the watchpoint condition expression. It should be
of the form "*<address> 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 *<address> EQUAL <literal>");
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