Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Thiago Jung Bauermann <bauerman@br.ibm.com>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
Subject: Re: [patch 2/2] Implement support for PowerPC BookE masked and ranged watchpoints
Date: Tue, 16 Nov 2010 04:01:00 -0000	[thread overview]
Message-ID: <20101116040116.GA19243@host0.dyn.jankratochvil.net> (raw)
In-Reply-To: <1288905125.14606.4.camel@hactar>

#       awatch-range 0xbffff8e8,0xbffff8f8


[...]
#       awatch *0xbffff8e8 mask 0xffffff00

What is the difference of this masked range versus?

        awatch-range 0xbffff800, 0xbffff8ff

If there is no difference then the mask address feature is useful only for
masks which are not of the form (-1 << n).


On Thu, 04 Nov 2010 22:12:05 +0100, Thiago Jung Bauermann wrote:
> +watch-range START_ADDR,+LENGTH | START_ADDR, END_ADDR
> +rwatch-range START_ADDR,+LENGTH | START_ADDR, END_ADDR
> +awatch-range START_ADDR,+LENGTH | START_ADDR, END_ADDR
> +  Set a hardware watchpoint for an address range.
> +  The watchpoint will stop execution of your program whenever the inferior
> +  writes, reads, or accesses (respectively for watch-range, awatch-range
> +  and rwatch-range) any address within the specified range.

What is the problem with the syntax?

watch *array@elementcount
OR
watch *(char *)array@bytescount

People already must know the @ operator just for printing arrays.  And some
nifty user friendly is provided by FE (graphical front end) and not CLI.

I may be biased but I would not try to invent new commands unless necessary,
GDB has already enough of them no user knows them all.


> +		target_resources_ok =  target_can_use_hardware_watchpoint

two spaces.


> +static int
> +insert_ranged_watchpoint (struct bp_location *bpt)

Like going to send in the other mail, `bpt' is (mostly) used for
`struct breakpoint'.  For bp_location please use `bl', `bploc' or some other
bp_location-suggesting names used in GDB.


> +  c = add_com ("watch-range", class_breakpoint, watch_range_command, _("\
> +Set a hardware watchpoint for an address range.\n\
> +The address range should be specified in one of the following formats:\n\
> +\n\
> +   start-address, end-address\n\
> +   start-address, +length\n\
> +\n\
> +The watchpoint will stop execution of the inferior whenever it\n\
> +writes to any address within the [start-address, end-address] range."));

I would prefer some explicit "both inclusively" statement there.
One could expect `end-address' to be the exclusive one.


> +/* Special types of hardware breakpoints/watchpoints.  */
> +enum hw_point_flag {

Incorrect GNU formatting.

> +	HW_POINT_RANGED_WATCH, /* Hardware ranged watchpoint.  */
> +	HW_POINT_MASKED_WATCH  /* Hardware masked watchpoint.  */
> +};


> +  p.version         = PPC_DEBUG_CURRENT_VERSION;

These extraneous spaces do not conform to GNU formatting.

> +  p.trigger_type    = get_trigger_type (rw);
> +  p.addr_mode       = PPC_BREAKPOINT_MODE_MASK;
> +  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
> +  p.addr            = (uint64_t) addr;
> +  p.addr2           = (uint64_t) mask;

Probably excessive cast.


> --- a/gdb/target.c
> +++ b/gdb/target.c
> @@ -601,11 +601,16 @@ update_current_target (void)
>        INHERIT (to_files_info, t);
>        INHERIT (to_insert_breakpoint, t);
>        INHERIT (to_remove_breakpoint, t);
> +      INHERIT (to_can_use_special_hw_point, t);

There are now two target interface styles in use.  This inheriting one and the
runtime-inheriting one (see target_pid_to_str and others).  I was told the
target_pid_to_str style is now preferred and it makes sense to me.  Please
convert the new target vector methods to the new style.


> +  if (addr_bit < (sizeof (CORE_ADDR) * HOST_CHAR_BIT))
> +  {

Wrong GNU formatting.

> +    address_start &= ((CORE_ADDR) 1 << addr_bit) - 1;
> +    address_end &= ((CORE_ADDR) 1 << addr_bit) - 1;
> +  }
> +
> +  /* FIXME: cagney/2002-05-03: Need local_address_string() function
> +     that returns the language localized string formatted to a width
> +     based on gdbarch_addr_bit.  */
> +  if (addr_bit <= 32)
> +  {

Wrong GNU formatting.

> +    strcpy (addstr, "[");
> +    strcat (addstr, hex_string_custom (address_start, 8));
> +    strcat (addstr, ", ");
> +    strcat (addstr, hex_string_custom (address_end, 8));
> +    strcat (addstr, "]");
> +  }
> +  else
> +  {

Wrong GNU formatting.

> --- a/gdb/ui-out.h
> +++ b/gdb/ui-out.h
> @@ -113,6 +113,12 @@ extern void ui_out_field_fmt_int (struct ui_out *uiout, int width,
>  				  enum ui_align align, const char *fldname, 
>  		 		  int value);
>  
> +extern void ui_out_field_range_core_addr (struct ui_out *uiout,
> +					  const char *fldname,
> +                                          struct gdbarch *gdbarch,

Spaces used instead of tabs.

> +					  CORE_ADDR address_start,
> +					  CORE_ADDR length);
> +


Thanks,
Jan


  reply	other threads:[~2010-11-16  4:01 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
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 [this message]
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=20101116040116.GA19243@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=bauerman@br.ibm.com \
    --cc=eliz@gnu.org \
    --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