support for BookE hardware debug features

support for BookE hardware debug features

[Thiago Jung Bauermann]

Hi folks,

This is a heads up message to mention some work we're doing to support
more BookE hardware debug features for userspace debugging under Linux,
which we intend to submit upstream. Perhaps someone out there has input
on this, or even want to help us. :-)

Right now GDB just supports one hardware watchpoint in embedded ppc
processors. We're adding support for:

- one more hardware watchpoint,
- four hardware breakpoints,
- support for the two DVCs (Data Value Compare), which enable
hardware-accelerated conditions for hardware watchpoints,
- two ranged hardware breakpoints,
- one ranged hardware watchpoint.

We're also working on the kernel side of the equation. We'll test it all
on the ppc440 processor.

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.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: support for BookE hardware debug features

[Joel Brobecker]

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

Re: support for BookE hardware debug features

[Thiago Jung Bauermann]

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

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

Re: support for BookE hardware debug features

[Joel Brobecker]

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

That should work, at least for now. The downside, as I was saying,
is that each target will possibly have to duplicate the expression
tree analysis. I more targets start popping up with this feature,
perhaps we'll have to think of a more generic approach where we pass
the result of the analysis to the hook rather than let the hook do
the analysis. In the meantime, it's probably not worth worrying too
much about genericity if only one target in the FSF tree supports it.
(our VxWorks implementation has still a couple of key parts that need
to be improved before we can think of contributing it)

> Regarding what is a viable approach, our main concern is that we do it
> in a way which will be accepted upstream.

I personally don't see any problem with that, if it's just a well
defined hook.

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

No problem at all, I wrote the code, and it's not confidential.
If it's any help to you, then by all means, use it in any way.

-- 
Joel

Re: support for BookE hardware debug features

[Thiago Jung Bauermann]

Hi all,

Em Seg, 2009-03-02 às 17:39 -0300, Thiago Jung Bauermann escreveu:
> Right now GDB just supports one hardware watchpoint in embedded ppc
> processors. We're adding support for:
> 
> - one more hardware watchpoint,
> - four hardware breakpoints,
> - support for the two DVCs (Data Value Compare), which enable
> hardware-accelerated conditions for hardware watchpoints,
> - two ranged hardware breakpoints,
> - one ranged hardware watchpoint.

Just to give a status update on this work: up to now we have the
following features implemented and fully functional:

- one more hardware watchpoint,
- four hardware breakpoints,
- one ranged hardware watchpoint.

The above are working for both native GDB and gdbserver, both on Linux.

> We're also working on the kernel side of the equation. We'll test it all
> on the ppc440 processor.

The kernel support is going along nicely, but since it's not ready nor
accepted upstream yet, we can't start posting our GDB patches that are
ready.

> We don't know yet how we'll extend gdb commands to express the ranged
> breakpoints and watchpoints, and the DVCs.

I implemented a "watch-range" command, which takes a start address (or
expression which evaluates to an address) and an end address (or
expression). Not sure if I'll keep it that way or change. Didn't think
much about it yet.

Also, I want GDB to automagically use the ranged watchpoint for big
structs and arrays.

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

We are just starting to work on the DVC (conditioned hw watchpoint), but
for now I'm inclined to use it automagically for simple expressions with
just one == or != operator. We're taking into account Joel's comments
and suggestions on this. Thanks Joel for your input!

Sérgio did most of the work here. I don't know if he wants to add
anything to this report...
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

Re: support for BookE hardware debug features

[Sérgio Durigan Júnior]

On Sun, 2009-05-24 at 16:38 -0300, Thiago Jung Bauermann wrote:

> I implemented a "watch-range" command, which takes a start address (or
> expression which evaluates to an address) and an end address (or
> expression). Not sure if I'll keep it that way or change. Didn't think
> much about it yet.

Just to complement (I don't know if it's worth mentioning, but
anyway...) it seems we may have found a little bug regarding
watchpoint's expression evaluation.  Basically, the problem was
occurring when GDB tried to see if a block of memory changed in order to
determine whether it should trigger the watchpoint.  GDB was basically
comparing the address of this memory region, and not the content itself,
which made it impossible to trigger the watchpoint.

Unfortunately, I don't have much details about this fix, but I think
Thiago can explain more (if needed).  Also, IIUC, this fix is not
related to the job we're doing so we could send it before we're able to
send other patches :-).

> We are just starting to work on the DVC (conditioned hw watchpoint), but
> for now I'm inclined to use it automagically for simple expressions with
> just one == or != operator. We're taking into account Joel's comments
> and suggestions on this. Thanks Joel for your input!

That is what I was thinking, too.  I don't know if it's possible to use
the DVC registers for more complex expressions, do you?

> Sérgio did most of the work here. I don't know if he wants to add
> anything to this report...

Thank you, the report is very good!

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil

Re: support for BookE hardware debug features

[Thiago Jung Bauermann]

Em Seg, 2009-05-25 às 16:19 -0300, Sérgio Durigan Júnior escreveu:
> On Sun, 2009-05-24 at 16:38 -0300, Thiago Jung Bauermann wrote:
> 
> > I implemented a "watch-range" command, which takes a start address (or
> > expression which evaluates to an address) and an end address (or
> > expression). Not sure if I'll keep it that way or change. Didn't think
> > much about it yet.
> 
> Just to complement (I don't know if it's worth mentioning, but
> anyway...) it seems we may have found a little bug regarding
> watchpoint's expression evaluation.  Basically, the problem was
> occurring when GDB tried to see if a block of memory changed in order to
> determine whether it should trigger the watchpoint.  GDB was basically
> comparing the address of this memory region, and not the content itself,
> which made it impossible to trigger the watchpoint.

Indeed. I was meaning to submit the fix as a separate patch, but I
forgot. Will regression test it and submit the fix ASAP.

> > We are just starting to work on the DVC (conditioned hw watchpoint), but
> > for now I'm inclined to use it automagically for simple expressions with
> > just one == or != operator. We're taking into account Joel's comments
> > and suggestions on this. Thanks Joel for your input!
> 
> That is what I was thinking, too.  I don't know if it's possible to use
> the DVC registers for more complex expressions, do you?

I think not, but I may be wrong. As we get more familiar with the
hardware feature, we'll see.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center