Re: [PATCH 0/2] Support the new PPC476 processor

[Daniel Jacobowitz <drow@false.org>]

On Wed, Dec 30, 2009 at 01:12:13AM -0200, Thiago Jung Bauermann wrote:
> I'm reluctant to remove the watch-range command though, because with the 
> artificial array syntax it's not straightforward to say "watch len *bytes* 
> starting at addr". Using:
> 
> watch *addr@len
> 
> is not correct, since it will watch len *integers* starting at addr. To do 
> what he/she wants, the user will have to type:
> 
> watch *((char *) addr)@len

This unintuitive command should also work:

  watch {char[len]} addr

It's not a very nice syntax though.
> They don't seem to be useful for C-level debugging, but can be for assembly-
> level debugging. For instance, if you have a block of code that has more than 
> one entrypoint and therefore you don't know where it will get jumped into, you 
> can put a ranged breakpoint to cover the entire block.

Also consider an unknown shared library as a block of code with
multiple entry points.

On Wed, Dec 30, 2009 at 10:45:31PM +0200, Eli Zaretskii wrote:
> > watch-range addr, +len
> 
> What would be the use-case for watching a range of addresses that is
> not an integral multiple of a variable's size?

With literal numbers GDB will use units of ints instead of bytes:

(gdb) ptype 0x10000000@32
type = int [32]

So "watch 0x10000000@32" will not have the expected effect.  This
is more likely to be useful when specifying the bare address rather
than a C-level variable, I think.

> Thanks for the explanations.  I think we should emulate this on
> architectures that don't have this in hardware (it doesn't sound
> hard).

How do you mean?  It seems basically impossible to me.

-- 
Daniel Jacobowitz
CodeSourcery