Re: support for BookE hardware debug features

[Joel Brobecker <brobecker@adacore.com>]

> - 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