Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [patch 2/2] Implement support for PowerPC BookE masked and ranged watchpoints
Date: Sat, 30 Oct 2010 07:13:00 -0000	[thread overview]
Message-ID: <83wrp05f2f.fsf@gnu.org> (raw)
In-Reply-To: <1288403952.2598.58.camel@hactar>

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: gdb-patches@sourceware.org
> Date: Fri, 29 Oct 2010 23:59:12 -0200
> 
> The version of the patch you reviewed wouldn't allow other architectures
> to create ranged software watchpoints (it asked the hardware whether the
> capability was available), though that was an unnecessary restriction.
> This version allows ranged software watchpoints for all architectures.
> (The change was made in the watch_range_command_1 function).

That's good to hear.  I think this is NEWS worthy, btw.

> > And what about masked watchpoints -- can they also be used in software
> > mode?
> 
> AFAIK, to implement masked watchpoints in software GDB would need to
> decode each instruction to see which address it was trying to access.
> This patch doesn't implement that, it would be hard work. If the target
> doesn't allow masked hardware watchpoints, the watch command will error
> out.

That's fine with me, I just wanted to make sure that documentation
faithfully reflects the implementation.

> > > +    case bp_hardware_watchpoint:
> > > +      ui_out_text (uiout, "Masked hardware watchpoint ");
> > 
> > Isn't it better to say "Masked hardware (write) watchpoint"?
> 
> Here I'm following the current GDB behaviour. It says just "Hardware
> watchpoint" for a bp_hardware_watchpoint.

OK.

> > > +  /* Display one line of extra information about this breakpoint,
> > > +     for "info breakpoints".  */
> > > +  void (*print_one_detail) (const struct breakpoint *, struct ui_out *);
> > 
> > Examples of such "extras" would be beneficial here.  Also, are there
> > any limitations on this extra information, like maximum length?
> 
> I changed this part to:
> 
>   /* Display extra information about this breakpoint, below the normal
>      breakpoint description in "info breakpoints".  In the example below,
>      the line with "memory range: [0x10094354, 0x100943a2]" was printed
>      by print_one_detail_ranged_watchpoint.
> 
>      (gdb) info breakpoints
>      Num     Type           Disp Enb Address    What
>      2       hw watchpoint  keep y              b
>              memory range: [0x10094354, 0x100943a2]
> 
>      */
>   void (*print_one_detail) (const struct breakpoint *, struct ui_out *);
> 
> What do you think?

I'm happy now.  Thanks.

> > > +  /* The watchpoint will trigger if the address of the memory access is
> > > +     within the defined range, as follows: p.addr <= address < p.addr2.  */
> > > +  p.addr            = (uint64_t) addr;
> > > +  p.addr2           = (uint64_t) addr + len;
> > 
> > But the documentation says that the end address is included, not
> > excluded.  Can we eliminate this source of confusion?
> 
> This code is in ppc-linux-nat.c right before calling ptrace to set the
> watchpoint, so it just documents how the kernel/processor interprets the
> parameters.
> 
> The user-facing code respects the semantics explained in the
> documentation. Also, target_insert_ranged_watchpoint takes a start
> address and a length as arguments and IMHO doesn't have this confusion.

Well, maybe this is worth a comment in this place.  Something like
"Note that this just documents how ptrace interprets its arguments;
the watchpoint is set to watch the defined range _inclusively_, as
specified by the user interface."

> gdb/doc/
> 	* gdb.texinfo (Set Watchpoints): Document mask parameter.
> 	(PowerPC Embedded): Document masked watchpoints and ranged watchpoints.

This part is approved.  Thanks.


  reply	other threads:[~2010-10-30  7:13 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17 19:42 Thiago Jung Bauermann
2010-10-07 14:48 ` Thiago Jung Bauermann
2010-10-23  4:23 ` Thiago Jung Bauermann
2010-10-23  9:07   ` Eli Zaretskii
2010-10-30  1:59     ` Thiago Jung Bauermann
2010-10-30  7:13       ` Eli Zaretskii [this message]
2010-11-01 21:47         ` Thiago Jung Bauermann
2010-11-02  3:53           ` Eli Zaretskii
2010-11-04 21:12             ` Thiago Jung Bauermann
2010-11-16  4:01               ` Jan Kratochvil
2010-11-18 17:26                 ` Joel Brobecker
2010-11-19 19:55                 ` Thiago Jung Bauermann
2010-11-19 23:45                   ` Joel Brobecker
2010-11-22 17:04                     ` Thiago Jung Bauermann
2010-11-22 17:38                       ` Joel Brobecker
2010-11-22 17:46                         ` Jan Kratochvil
2010-11-22 18:37                           ` Joel Brobecker
2010-11-20  5:00                   ` Joel Brobecker
2010-11-23 22:05                     ` 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=83wrp05f2f.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=bauerman@br.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /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