Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 5/7] range stepping: New command 'maint set range stepping'
Date: Tue, 14 May 2013 18:31:00 -0000	[thread overview]
Message-ID: <51928317.9000601@redhat.com> (raw)
In-Reply-To: <1363006291-13334-6-git-send-email-yao@codesourcery.com>

On 03/11/2013 12:51 PM, Yao Qi wrote:

> @@ -4647,6 +4651,7 @@ remote_vcont_probe (struct remote_state *rs)
>        support_C = 0;
>        rs->support_vCont.t = 0;
>        rs->support_vCont.r = 0;
> +      use_range_stepping = 0;
>        while (p && *p == ';')
>  	{
>  	  p++;
> @@ -4661,7 +4666,10 @@ remote_vcont_probe (struct remote_state *rs)
>  	  else if (*p == 't' && (*(p + 1) == ';' || *(p + 1) == 0))
>  	    rs->support_vCont.t = 1;
>  	  else if (*p == 'r' && (*(p + 1) == ';' || *(p + 1) == 0))
> -	    rs->support_vCont.r = 1;
> +	    {
> +	      rs->support_vCont.r = 1;
> +	      use_range_stepping = 1;
> +	    }

I don't think this is a good approach.  :-(  If the user does
"maint set range-stepping", and then connects, she'll reasonably
assume range stepping will be disabled.  She could have a stub that
has known broken range stepping, for example.  However, with this
approach, if the target supports it, range stepping will always end
up forced enabled as soon as GDB sends the first vCont packet, even
if the user set range stepping off.

So I think the "maint set range-stepping" toggle should be enabled
by default, and it should only represent GDB's willingness to use
the feature.

>  
>  	  p = strchr (p, ';');
>  	}
> @@ -4708,6 +4716,8 @@ append_resumption (char *p, char *endp,
>  
>        pc = regcache_read_pc (get_thread_regcache (ptid));
>        if (rs->support_vCont.r /* Target supports step range.  */
> +	  /* GDB is willing to do range stepping.  */
> +	  && use_range_stepping
>  	  /* Can't do range stepping for all threads of a process
>  	     'pPID.-1'.  */
>  	  && !(remote_multi_process_p (rs) && ptid_is_pid (ptid))
> @@ -11488,6 +11498,45 @@ remote_upload_trace_state_variables (struct uploaded_tsv **utsvp)
>    return 0;
>  }
>  
> +static void
> +maint_show_range_stepping (struct ui_file *file, int from_tty,
> +			   struct cmd_list_element *c,
> +			   const char *value)
> +{
> +  fprintf_filtered (file,
> +		    _("Debugger's willingness to do range-stepping "
> +		      "is %s.\n"), value);
> +}
> +
> +static void
> +maint_set_range_stepping (char *ignore_args, int from_tty,
> +			  struct cmd_list_element *c)
> +{
> +  /* Check range stepping is supported when turns it on.  */
> +  if (use_range_stepping)
> +    {
> +      if (remote_desc != NULL)
> +	{
> +	  struct remote_state *rs = get_remote_state ();
> +
> +	  if (remote_protocol_packets[PACKET_vCont].support == PACKET_SUPPORT_UNKNOWN)
> +	    remote_vcont_probe (rs);
> +
> +	  if (remote_protocol_packets[PACKET_vCont].support == PACKET_DISABLE
> +	      || !rs->support_vCont.r)

If we check instead for PACKET_ENABLE && rs->support_vCont.r here,


> +	    {
> +	      use_range_stepping = 0;
> +	      error (_("Range stepping is not supported"));
> +	    }
> +	}
> +      else
> +	{
> +	  use_range_stepping = 0;
> +	  error (_("Range stepping is not supported"));
> +	}

Then we can merge these two errors.  Following up on the "willingness-only"
idea, I'd rather make this a warning though.

In v3, I've make moved the setting out of "maint".

-- 
Pedro Alves


  parent reply	other threads:[~2013-05-14 18:31 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-11 12:52 [PATCH 0/7] Range stepping Yao Qi
2013-03-11 12:53 ` [PATCH 4/7] range stepping: gdb Yao Qi
2013-05-14 18:31   ` Pedro Alves
2013-05-15  8:07     ` Yao Qi
2013-05-20 17:59       ` Pedro Alves
2013-03-11 12:53 ` [PATCH 5/7] range stepping: New command 'maint set range stepping' Yao Qi
2013-03-11 17:05   ` Eli Zaretskii
2013-03-18  3:10     ` Yao Qi
2013-03-18  5:39       ` Eli Zaretskii
2013-05-14 18:31   ` Pedro Alves [this message]
2013-03-11 12:53 ` [PATCH 6/7] range stepping: test case Yao Qi
2013-05-14 18:32   ` Pedro Alves
2013-05-15  8:27     ` Yao Qi
2013-05-20 18:29       ` Pedro Alves
2013-05-22 14:01         ` Yao Qi
2013-03-11 12:53 ` [PATCH 1/7] New macro THREAD_WITHIN_SINGLE_STEP_RANGE Yao Qi
2013-05-14 19:24   ` Pedro Alves
2013-03-11 12:53 ` [PATCH 3/7] range stepping: gdbserver on x86/linux Yao Qi
2013-05-14 18:30   ` Pedro Alves
2013-05-15  7:40     ` Yao Qi
2013-05-20 18:00       ` Pedro Alves
2013-05-22 10:06         ` Yao Qi
2013-03-11 12:53 ` [PATCH 2/7] Move rs->support_vCont_t to a separate struct Yao Qi
2013-03-11 12:53 ` [PATCH 7/7] range stepping: doc and NEWS Yao Qi
2013-03-11 13:38   ` Abid, Hafiz
2013-03-11 17:01   ` Eli Zaretskii
2013-05-14 18:32   ` Pedro Alves
2013-03-14 20:12 ` [PATCH 0/7] Range stepping Pedro Alves
2013-03-15 19:54   ` Pedro Alves
2013-03-22  2:25     ` Yao Qi
2013-03-22 20:24       ` Pedro Alves
2013-04-11  6:16 ` [PATCH 0/7 V2] " Yao Qi
2013-04-11  6:17   ` [PATCH 1/7] New macro THREAD_WITHIN_SINGLE_STEP_RANGE Yao Qi
2013-04-11  6:17   ` [PATCH 2/7] Move rs->support_vCont_t to a separate struct Yao Qi
2013-04-11  6:18   ` [PATCH 3/7] range stepping: gdbserver on x86/linux Yao Qi
2013-04-11  6:19   ` [PATCH 5/7] range stepping: New command 'maint set range stepping' Yao Qi
2013-04-11 23:00     ` Eli Zaretskii
2013-04-11  6:19   ` [PATCH 4/7] range stepping: gdb Yao Qi
2013-04-11 13:22     ` Yao Qi
2013-04-12 12:35       ` Yao Qi
2013-04-11  6:38   ` [PATCH 6/7] range stepping: test case Yao Qi
2013-04-11  7:30   ` [PATCH 7/7] range stepping: doc and NEWS Yao Qi
2013-04-11 23:00     ` Eli Zaretskii
2013-04-12 20:48   ` [PATCH 0/7 V2] Range stepping Pedro Alves

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=51928317.9000601@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=yao@codesourcery.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