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.
next prev parent 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