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

Daniel Jacobowitz
2009-12-30T22:15:45Z

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