From: Eli Zaretskii <eliz@gnu.org>
To: "Sérgio Durigan Júnior" <sergiodj@linux.vnet.ibm.com>
Cc: gdb-patches@sourceware.org, bauerman@br.ibm.com,
luisgpm@linux.vnet.ibm.com, tyrlik@us.ibm.com
Subject: Re: [PATCH 0/2] Support the new PPC476 processor
Date: Fri, 18 Dec 2009 10:19:00 -0000 [thread overview]
Message-ID: <83y6l060qp.fsf@gnu.org> (raw)
In-Reply-To: <200912161847.17162.sergiodj@linux.vnet.ibm.com>
> 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?
next prev parent reply other threads:[~2009-12-18 10:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-16 20:48 Sérgio Durigan Júnior
2009-12-17 4:42 ` Joel Brobecker
2009-12-17 14:19 ` Thiago Jung Bauermann
2009-12-17 16:15 ` Sérgio Durigan Júnior
2009-12-18 10:19 ` Eli Zaretskii [this message]
2009-12-20 12:33 ` Joel Brobecker
2009-12-30 3:13 ` Thiago Jung Bauermann
2009-12-30 20:43 ` Eli Zaretskii
2009-12-30 22:15 ` Daniel Jacobowitz
2009-12-31 4:05 ` Eli Zaretskii
2009-12-31 16:28 ` Daniel Jacobowitz
2009-12-31 16:50 ` Pedro Alves
2009-12-20 13:16 ` Joel Brobecker
2009-12-20 15:09 ` Sérgio Durigan Júnior
2009-12-20 18:24 ` Joel Brobecker
2009-12-21 12:54 ` Thiago Jung Bauermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83y6l060qp.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=bauerman@br.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=luisgpm@linux.vnet.ibm.com \
--cc=sergiodj@linux.vnet.ibm.com \
--cc=tyrlik@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox