[PATCH 0/2] Support the new PPC476 processor

[PATCH 0/2] Support the new PPC476 processor

[Sérgio Durigan Júnior]

Hello guys!

Long time no see!  I have been following the e-mails on the list, but 
unfortunately I was too busy to join any discussion.  Well, hopefully now I 
will be able to breath a little bit :-).

This series of patches implement the support for the new PowerPC 476 IBM 
processor.  This is an embedded processor with some nice debugging 
capabilities, and I believe you will like to see the new types of 
breakpoints/watchpoints implemented on GDB.  Here's a brief explanation of the 
new features, with some examples (credit goes to Luis Machado for this 
explanation):

The following features are enabled by the patch:

  * Hardware Watchpoints (separate items are mutually exclusive)
    o 2 x Hardware Watchpoints with/without data value check
    o 1 x Range Hardware Watchpoint
    o 1 x Mask Hardware Watchpoint

  * Hardware Breakpoints (separate items are mutually exclusive)
    o 4 x Hardware Breakpoints
    o 2 x Range Hardware Breakpoints

---= Hardware Watchpoints =---

  * Simple Hardware Watchpoints: Monitors accesses to a single data address.  
For the PPC476, 2 of them are available provided that no Range/Mask 
watchpoints are being used.  There is also the possibility of using conditions 
when monitoring the values.  In this case, GDB will place the condition inside 
a register, and the evaluation will be hardware-accelerated, which will speed-
up significantly the debugging process.  The PPC476 processor has two 
registers that can be used to hardware-accelerate the condition evaluation.

    - Available GDB commands: [r|a]watch <variable> (rwatch/awatch/watch) or 
[r|a]watch <variable> if <variable> == <4-bytes unsigned constant>

    - Usage example: awatch i / rwatch *0xbffff8e8 / watch i if i == 28

  * Range Hardware Watchpoints: Monitors accesses to an interval of data 
addresses.  For the 476, a single Range Hardware Watchpoint can be used 
provided that no Simple/Mask watchpoints are being used.

    - Available GDB commands: [r|a]watch-range <address1>:<address2 | +<uint 
length>>, where <address1> <= <address2> (rwatch-range/awatch-range/watch-
range)

    - Usage example: watch-range &i,&k / awatch-range 0xbffff8e8,0xbffff8f8 / 
rwatch-range 0xbffff8e8,+8

  * Mask Hardware Watchpoints: Monitors accesses to data addresses that match 
a specific pattern.  For the 476, a single Mask Hardware Watchpoint can be 
used provided that no Simple/Range watchpoints are being used.  Due to the 
processor's design, the precise data address of the watchpoint trigger is not 
available, so the user must check the instruction that caused the trigger 
(usually at PC - 4) to obtain such data address.  With such data address in 
hand, it's possible to tell if its contents have changed.

    - Available GDB commands: [r|a]watch <variable | address> mask 
<mask_value>

    - Usage example: watch i mask 0xffffff00 / awatch *0xbffff8e8 mask 
0xffffff00


  Since the Simple/Range/Mask Hardware Watchpoints share the same register 
set, the allowed combinations are as follows:

  - 2 Simple Hardware Watchpoints with/without data value check

  - 1 Range Hardware Watchpoint

  - 1 Mask Hardware Watchpoint

---= Hardware Breakpoints =---

  * Simple Hardware Breakpoint: Monitors a single instruction address.

    - Available GDB commands: hbreak <address> / hbreak <line number>

    - Usage example: hbreak *0x10000658 / hbreak 20

  * Range Hardware Breakpoint: Monitors an interval of instruction addresses.

    - Available GDB commands: hbreak-range <address1>:<address2 | +<unsigned 
int length>> where <address1> <= <address2> / hbreak-range <line number 
start>:<line number end>

    - Usage example: hbreak-range 0x10000658,0x10000660 / hbreak-range 
0x10000658,+8 / hbreak-range 20,30

  Since the Simple and Range variations share the same register set, the 
allowed combinations of Simple Hardware Breakpoints (HW Break) and Range 
Hardware Breakpoints (Range HW Break) are as follows:

  - 4 HW Breaks

  - 1 or 2 HW Breaks / 1 Range HW Break

  - 2 Range HW Breaks

----

When you review the patches, you will notice that they use a few declarations, 
defines and statements that do not exist yet.  This is because we defined a 
new interface with the kernel guys from IBM that provides such features.  This 
interface has been defined in collaboration with Benjamin Herrenschmidt (among 
others), who is the current maintainer of the PowerPC kernel tree.  Also, the 
patch for this new interface has already been posted and is being reviewed by 
the developers, and the comments received so far do not mention anything about 
changing the interface, so it is guaranteed that this interface will be 
accepted upstream as-is.

Unfortunately, this patch does not compile if the PowerPC machine doesn't have 
the updated kernel (with the new interface), but we will fix it ASAP.  I have 
chosen to post it even with this problem in order to let you guys have time to 
review and comment about the code.

It is also important to mention that I still have not written the 
documentation for the new features, nor a testcase.  I plan do that as the 
review process occurs.

Please, let me know if there is anything unclear about this patch.

Best regards,

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

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

[Joel Brobecker]

I'm very excited to see hardware-accelerated condition evaluation.
I'll take a look at the patches for sure.

Regarding the need for very recent kernel headers, it might be an issue.
I assume the missing pieces are for the special kinds of watchpoints and
breakpoints. Is there a way to disable just this code if the kernel
is not recent enough?

-- 
Joel

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

[Thiago Jung Bauermann]

On Thu 17 Dec 2009 02:42:12 Joel Brobecker wrote:
> I'm very excited to see hardware-accelerated condition evaluation.
> I'll take a look at the patches for sure.

Great!

> Regarding the need for very recent kernel headers, it might be an issue.
> I assume the missing pieces are for the special kinds of watchpoints and
> breakpoints. Is there a way to disable just this code if the kernel
> is not recent enough?
 
We do intend that GDB keeps compiling and working as before when the kernel is 
not recent enough. But then none of the new features this patch adds will be 
available. The current ptrace interface for BookE debug registers
is an ugly hack, and GDB already does everything that can be done with it, 
namely support just one hardware watchpoint, and no hardware breakpoint.

That is because the current ptrace interface was designed for server Power 
processors, which only have one hardware watchpoint anyway.

By the way, the kernel patch implementing the new interface used by this
patch series is here:

http://lists.ozlabs.org/pipermail/linuxppc-dev/2009-December/078805.html
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

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

[Sérgio Durigan Júnior]

Hi Joel,

On Thursday 17 December 2009, Joel Brobecker wrote:
> I'm very excited to see hardware-accelerated condition evaluation.
> I'll take a look at the patches for sure.

Thanks!

> Regarding the need for very recent kernel headers, it might be an issue.
> I assume the missing pieces are for the special kinds of watchpoints and
> breakpoints. Is there a way to disable just this code if the kernel
> is not recent enough?

Yeah, we will certainly want to disable this special code if the kernel 
doesn't support the feature.  We will post a patch for it ASAP, but it 
shouldn't change anything important on the current version of the patch, so if 
you want to start reviewing it, be my guest :-).

Thank you,

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

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

[Eli Zaretskii]

> From: Sérgio_Durigan_Júnior <sergiodj@linux.vnet.ibm.com>
> Date: Wed, 16 Dec 2009 18:47:16 -0200
> Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>,         Luis Machado <luisgpm@linux.vnet.ibm.com>,         Matt Tyrlik <tyrlik@us.ibm.com>
> 
> This series of patches implement the support for the new PowerPC 476 IBM 
> processor.  This is an embedded processor with some nice debugging 
> capabilities, and I believe you will like to see the new types of 
> breakpoints/watchpoints implemented on GDB.

Thanks!

I have a few preliminary comments and questions about the proposed UI:

>   * Simple Hardware Watchpoints: Monitors accesses to a single data address.  
> For the PPC476, 2 of them are available provided that no Range/Mask 
> watchpoints are being used.  There is also the possibility of using conditions 
> when monitoring the values.  In this case, GDB will place the condition inside 
> a register, and the evaluation will be hardware-accelerated, which will speed-
> up significantly the debugging process.  The PPC476 processor has two 
> registers that can be used to hardware-accelerate the condition evaluation.
> 
>     - Available GDB commands: [r|a]watch <variable> (rwatch/awatch/watch) or 
> [r|a]watch <variable> if <variable> == <4-bytes unsigned constant>
> 
>     - Usage example: awatch i / rwatch *0xbffff8e8 / watch i if i == 28

Will GDB decide automatically whether to use hardware-accelerated
conditions or the current implementation, whereby an unconditional
hardware watchpoint is set, and when it breaks, GDB itself evaluates
the condition?  I think this should be done automatically.

>   * Range Hardware Watchpoints: Monitors accesses to an interval of data 
> addresses.  For the 476, a single Range Hardware Watchpoint can be used 
> provided that no Simple/Mask watchpoints are being used.
> 
>     - Available GDB commands: [r|a]watch-range <address1>:<address2 | +<uint 
> length>>, where <address1> <= <address2> (rwatch-range/awatch-range/watch-
> range)
> 
>     - Usage example: watch-range &i,&k / awatch-range 0xbffff8e8,0xbffff8f8 / 
> rwatch-range 0xbffff8e8,+8

Why is there a need for a separate GDB command?  What are the
use-cases where the user would want to watch a region that is spanned
by more than one (albeit large) variable?  If such use-cases are
infrequent enough or obscure, then we could simply use the normal
watch commands, and support any corner use-cases with something like

   watch *0xbffff8e8@8

using what is a normal GDB semantics for artificial arrays.  IOW, no
need for either the comma-separated list of 2 addresses or a separate
command.

>   * Mask Hardware Watchpoints: Monitors accesses to data addresses that match 
> a specific pattern.  For the 476, a single Mask Hardware Watchpoint can be 
> used provided that no Simple/Range watchpoints are being used.  Due to the 
> processor's design, the precise data address of the watchpoint trigger is not 
> available, so the user must check the instruction that caused the trigger 
> (usually at PC - 4) to obtain such data address.  With such data address in 
> hand, it's possible to tell if its contents have changed.
> 
>     - Available GDB commands: [r|a]watch <variable | address> mask 
> <mask_value>
> 
>     - Usage example: watch i mask 0xffffff00 / awatch *0xbffff8e8 mask 
> 0xffffff00

I'm not sure about the semantics of this: what exactly does the mask
do? how does it modify the unmasked command for the same address?

>   * Range Hardware Breakpoint: Monitors an interval of instruction addresses.
> 
>     - Available GDB commands: hbreak-range <address1>:<address2 | +<unsigned 
> int length>> where <address1> <= <address2> / hbreak-range <line number 
> start>:<line number end>
> 
>     - Usage example: hbreak-range 0x10000658,0x10000660 / hbreak-range 
> 0x10000658,+8 / hbreak-range 20,30

Again, what are the use-cases where such breakpoints would be useful?

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

[Joel Brobecker]

> >     - Usage example: watch-range &i,&k / awatch-range 0xbffff8e8,0xbffff8f8 / 
> > rwatch-range 0xbffff8e8,+8
> 
> Why is there a need for a separate GDB command?  What are the
> use-cases where the user would want to watch a region that is spanned
> by more than one (albeit large) variable?  If such use-cases are
> infrequent enough or obscure, then we could simply use the normal
> watch commands, and support any corner use-cases with something like
> 
>    watch *0xbffff8e8@8

FWIW, I actually prefer the seperate command over your suggestion.
The use of the @8 seems logical, but '@' is little known and the
new command seems more explicit about the actual range being watched.

-- 
Joel

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

[Joel Brobecker]

Sergio,

I did a quick pass over the patch that you sent, and I pretty much
agree with the comments made by Eli.  My general comment, is that
the patch is too big for me to really digest as is (3,000 lines in
total!)- maybe it's just me being preoccupied with some many things
going on at the same time.  If you'd like to help me review your changes,
I suggest we take a different approach than the one you took to present
these patches: I'd like to have a set of independent patches that implement
each feature independently (that way, I don't have to try to determine
which feature each hunk applies to). We don't have to have them all,
in fact, I'd feel less overwhelmed if we started with just one feature.
For instance, we could look at hardware-accelerated watchpoint conds.
We could look at watchpoint ranges, but we are still discussing the user
interface...

One stylistic comment is that I'm having a hard time with the use of
"point" to mean either breakpoint or watchpoint. I wonder if we could
find something else, but nothing really comes to mind. I am tempted
to say that watchpoints are really data breakpoints while breakpoints
are instruction breakpoints (this is how some documents that I read
called watchpoints: data breakpoints), but perhaps using breakpoint
in this case is going to just be too confusing in the GDB context.
Hmmmm....

-- 
Joel

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

[Sérgio Durigan Júnior]

Hi Joel,

On Sun, Dec 20, 2009 at 11:15 AM, Joel Brobecker <brobecker@adacore.com> wrote:

> I did a quick pass over the patch that you sent, and I pretty much
> agree with the comments made by Eli.  My general comment, is that
> the patch is too big for me to really digest as is (3,000 lines in
> total!)- maybe it's just me being preoccupied with some many things
> going on at the same time.  If you'd like to help me review your changes,
> I suggest we take a different approach than the one you took to present
> these patches: I'd like to have a set of independent patches that implement
> each feature independently (that way, I don't have to try to determine
> which feature each hunk applies to). We don't have to have them all,
> in fact, I'd feel less overwhelmed if we started with just one feature.
> For instance, we could look at hardware-accelerated watchpoint conds.
> We could look at watchpoint ranges, but we are still discussing the user
> interface...

I am sorry about that.  When I sent the patch, I decided to use the
same approach that I used for the catch syscall series, but apparently
it wasn't a good idea.

I will see what I can do in order to get the patches divided the way
you want; I don't think it will be hard to accomplish that.  Thiago is
probably going to resubmit the patches, since I'm not working at IBM
anymore (that's the reason why I haven't replied to Eli's messages, by
the way).

> One stylistic comment is that I'm having a hard time with the use of
> "point" to mean either breakpoint or watchpoint. I wonder if we could
> find something else, but nothing really comes to mind. I am tempted
> to say that watchpoints are really data breakpoints while breakpoints
> are instruction breakpoints (this is how some documents that I read
> called watchpoints: data breakpoints), but perhaps using breakpoint
> in this case is going to just be too confusing in the GDB context.
> Hmmmm....

When I decided to use this term, I based that decision on the fact
that gdbserver uses the same nomenclature:  for example, it has a
variable called `debug_hw_points', the methods `insert_point' and
`remove_point', etc.  But of course, if you think this term is
confusing, we should be able to find a better one :-).

Thank you for the pre-review!

Sérgio.

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

[Joel Brobecker]

> I am sorry about that.  When I sent the patch, I decided to use the
> same approach that I used for the catch syscall series, but apparently
> it wasn't a good idea.

Not to worry. This is probably a matter of personal taste too, which
is why I did not demand, but rather ask if it was possible. In particular,
if someone else manages to review these patches, I'm prefectly happy.

> When I decided to use this term, I based that decision on the fact
> that gdbserver uses the same nomenclature:  for example, it has a
> variable called `debug_hw_points', the methods `insert_point' and
> `remove_point', etc.

A very valid ... point! :-). If this is an already established
nomenclature, then this is fine. I don't see the point of changing now.

-- 
Joel

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

[Thiago Jung Bauermann]

On Sun 20 Dec 2009 16:23:56 Joel Brobecker wrote:
> > I am sorry about that.  When I sent the patch, I decided to use the
> > same approach that I used for the catch syscall series, but apparently
> > it wasn't a good idea.
> 
> Not to worry. This is probably a matter of personal taste too, which
> is why I did not demand, but rather ask if it was possible. In particular,
> if someone else manages to review these patches, I'm prefectly happy.

Actually, I'm in the middle of converting the patch into an incremental 
series. I'll post it shortly.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

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

[Thiago Jung Bauermann]

Hi Eli,

Thanks for the review!

On Fri 18 Dec 2009 08:21:50 Eli Zaretskii wrote:
> I have a few preliminary comments and questions about the proposed UI:
> >   * Simple Hardware Watchpoints: Monitors accesses to a single data
> > address. For the PPC476, 2 of them are available provided that no
> > Range/Mask watchpoints are being used.  There is also the possibility of
> > using conditions when monitoring the values.  In this case, GDB will
> > place the condition inside a register, and the evaluation will be
> > hardware-accelerated, which will speed- up significantly the debugging
> > process.  The PPC476 processor has two registers that can be used to
> > hardware-accelerate the condition evaluation.
> >
> >     - Available GDB commands: [r|a]watch <variable> (rwatch/awatch/watch)
> > or [r|a]watch <variable> if <variable> == <4-bytes unsigned constant>
> >
> >     - Usage example: awatch i / rwatch *0xbffff8e8 / watch i if i == 28
> 
> Will GDB decide automatically whether to use hardware-accelerated
> conditions or the current implementation, whereby an unconditional
> hardware watchpoint is set, and when it breaks, GDB itself evaluates
> the condition?  I think this should be done automatically.

Yes, GDB will use hardware-accelerated conditions automatically, when 
available on the target.

> >   * Range Hardware Watchpoints: Monitors accesses to an interval of data
> > addresses.  For the 476, a single Range Hardware Watchpoint can be used
> > provided that no Simple/Mask watchpoints are being used.
> >
> >     - Available GDB commands: [r|a]watch-range <address1>:<address2 |
> > +<uint length>>, where <address1> <= <address2>
> > (rwatch-range/awatch-range/watch- range)
> >
> >     - Usage example: watch-range &i,&k / awatch-range
> > 0xbffff8e8,0xbffff8f8 / rwatch-range 0xbffff8e8,+8
> 
> Why is there a need for a separate GDB command?  What are the
> use-cases where the user would want to watch a region that is spanned
> by more than one (albeit large) variable?  If such use-cases are
> infrequent enough or obscure, then we could simply use the normal
> watch commands, and support any corner use-cases with something like
> 
>    watch *0xbffff8e8@8
> 
> using what is a normal GDB semantics for artificial arrays.  IOW, no
> need for either the comma-separated list of 2 addresses or a separate
> command.

I agree that it is convenient to support ranged watchpoints with an 
established GDB syntax. So I implemented that. If the user asks to watch an 
array (natural or artificial) or struct, and ranged watchpoints are available 
then it will use them automatically.

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

Compare with:

watch-range addr, +len

(or perhaps I'm missing a simpler way to use artificial arrays in the example 
above..)

> >   * Mask Hardware Watchpoints: Monitors accesses to data addresses that
> > match a specific pattern.  For the 476, a single Mask Hardware Watchpoint
> > can be used provided that no Simple/Range watchpoints are being used. 
> > Due to the processor's design, the precise data address of the watchpoint
> > trigger is not available, so the user must check the instruction that
> > caused the trigger (usually at PC - 4) to obtain such data address.  With
> > such data address in hand, it's possible to tell if its contents have
> > changed.
> >
> >     - Available GDB commands: [r|a]watch <variable | address> mask
> > <mask_value>
> >
> >     - Usage example: watch i mask 0xffffff00 / awatch *0xbffff8e8 mask
> > 0xffffff00
> 
> I'm not sure about the semantics of this: what exactly does the mask
> do? how does it modify the unmasked command for the same address?

The mask makes the processor ignore the address bits that are 0 in the mask 
when matching the data access address. In the example above, the watchpoint 
will hit whenever there's a memory access to an address that is equal to the 
address of i, but ignoring the last eight bits in the comparison.
The PowerPC 440 user manual has an interesting example:

  This comparison mode is useful for detecting accesses to a particular byte 
  address, when the accesses may be of various sizes. For example, if the 
  debugger is interested in detecting accesses to byte address 0x00000003, 
  then these accesses may occur due to a byte access to that specific address, 
  or due to a halfword access to address 0x00000002, or due to a word access 
  to address 0x00000000. By using address bit mask mode and specifying that 
  the low-order two bits of the address should be ignored (that is, setting 
  the address bit mask in DAC2 to 0xFFFFFFFC), the debugger can detect each of 
  these types of access to byte address 0x00000003.

> >   * Range Hardware Breakpoint: Monitors an interval of instruction
> > addresses.
> >
> >     - Available GDB commands: hbreak-range <address1>:<address2 |
> > +<unsigned int length>> where <address1> <= <address2> / hbreak-range
> > <line number start>:<line number end>
> >
> >     - Usage example: hbreak-range 0x10000658,0x10000660 / hbreak-range
> > 0x10000658,+8 / hbreak-range 20,30
> 
> Again, what are the use-cases where such breakpoints would be useful?
 
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.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center

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

[Eli Zaretskii]

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Date: Wed, 30 Dec 2009 01:12:13 -0200
> Cc: luisgpm@linux.vnet.ibm.com, tyrlik@us.ibm.com
> 
> > >     - Available GDB commands: [r|a]watch <variable> (rwatch/awatch/watch)
> > > or [r|a]watch <variable> if <variable> == <4-bytes unsigned constant>
> > >
> > >     - Usage example: awatch i / rwatch *0xbffff8e8 / watch i if i == 28
> > 
> > Will GDB decide automatically whether to use hardware-accelerated
> > conditions or the current implementation, whereby an unconditional
> > hardware watchpoint is set, and when it breaks, GDB itself evaluates
> > the condition?  I think this should be done automatically.
> 
> Yes, GDB will use hardware-accelerated conditions automatically, when 
> available on the target.

That's good to hear, thanks.

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

> > >     - Available GDB commands: hbreak-range <address1>:<address2 |
> > > +<unsigned int length>> where <address1> <= <address2> / hbreak-range
> > > <line number start>:<line number end>
> > >
> > >     - Usage example: hbreak-range 0x10000658,0x10000660 / hbreak-range
> > > 0x10000658,+8 / hbreak-range 20,30
> > 
> > Again, what are the use-cases where such breakpoints would be useful?
>  
> 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.

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

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

[Daniel Jacobowitz]

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

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

[Eli Zaretskii]

> Date: Wed, 30 Dec 2009 17:15:35 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com,
> 	tyrlik@us.ibm.com
> 
> > 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.

How is it impossible to put several breakpoints covering a range of
addresses?

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

[Daniel Jacobowitz]

On Thu, Dec 31, 2009 at 06:06:48AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 30 Dec 2009 17:15:35 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com,
> > 	tyrlik@us.ibm.com
> > 
> > > 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.
> 
> How is it impossible to put several breakpoints covering a range of
> addresses?

I think ranged breakpoints are typically used with a large range of
addresses.  For instance, I can imagine using them to cover an entire
shared library - say 1MB of code.  Also we don't know which part of
the range is code and which is data, so using software breakpoints
indiscriminately could break the program.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Pedro Alves]

On Thursday 31 December 2009 16:27:59, Daniel Jacobowitz wrote:
> On Thu, Dec 31, 2009 at 06:06:48AM +0200, Eli Zaretskii wrote:
> > > Date: Wed, 30 Dec 2009 17:15:35 -0500
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: gdb-patches@sourceware.org, luisgpm@linux.vnet.ibm.com,
> > > 	tyrlik@us.ibm.com
> > > 
> > > > 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.
> > 
> > How is it impossible to put several breakpoints covering a range of
> > addresses?
> 
> I think ranged breakpoints are typically used with a large range of
> addresses.  For instance, I can imagine using them to cover an entire
> shared library - say 1MB of code.  Also we don't know which part of
> the range is code and which is data, so using software breakpoints
> indiscriminately could break the program.

There are systems with unlimited hardware watchpoints, though.
Then, there's always the last resort of of single-stepping all-the-way, and
implementing "breakpoints" by stopping when the PC steps into
breakpointed area, a-la software watchpoints.
Also, and nicer, systems with a MMU can implement this without special
debug register support.  E.g., by setting the watched/breakpointed
pages to unreadable/unwritable, and trapping on page
faults (filtering out hits that are uninteresting, of course) --- works
best with OS/paging coordination.  Wasn't it Solaris' procfs that
implemented this? 

-- 
Pedro Alves