public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: Christina Schimpe <christina.schimpe@intel.com>,
	gdb-patches@sourceware.org
Cc: tom@tromey.com, aburgess@redhat.com, eliz@gnu.org
Subject: Re: [PATCH v4 3/3] gdb: Remove workaround for the vCont packet
Date: Mon, 23 Jan 2023 17:46:07 +0000	[thread overview]
Message-ID: <32fd8757-bc08-07d1-bbdd-f6da30137bc8@palves.net> (raw)
In-Reply-To: <20221221133958.2111768-4-christina.schimpe@intel.com>

On 2022-12-21 1:39 p.m., Christina Schimpe wrote:
> The workaround for the vCont packet is no longer required due to the
> former commit "gdb: Make global feature array a per-remote target array".
> The vCont packet is now checked once when the connection is started and
> the supported vCont actions are set to the target's remote state
> attribute.

So this patch is actually doing two things:

 #1 - removing the supports_vCont_probed hack.

 #2 - moving the vCont probing earlier, to connection start.

To eliminate the workaround, you don't need #2.  Doing just #1 would simply get us back
to how it worked before the multi-target support.  #2 is an extra change.

I don't think there's any particular reason for deferring probing for vCont
support up until we first try to resume.  Looking at the history, we find that
vCont was designed in 2003, here:

  https://marc.info/?l=gdb-patches&w=2&r=30&s=vcont&q=b

and particularly "vCont?" probing was discussed here:

  https://marc.info/?l=gdb-patches&m=158570765842635&w=2

while the qSupported generic probing feature (done at connection startup) was only
invented later in 2006:

  https://sourceware.org/legacy-ml/gdb/2006-05/msg00372.html

Even without qSupported (otherwise I bet we wouldn't have vCont? but instead the support
would have been reported via qSupported), it's not clear why Daniel didn't do the probing at
initial connection time, I didn't find any message specifically about that.  Likely it was
written that way just to keep all the related code together, I guess.

Thus, the patch is OK.  But I wanted to explicitly state the two unrelated changes here
for the record, and dig a bit at the history to figure out whether we'd be breaking
some subtle use case.

Thanks for this.  Happy to see it finally done.

Pedro Alves

> ---
>  gdb/remote.c | 23 ++++-------------------
>  1 file changed, 4 insertions(+), 19 deletions(-)
> 
> diff --git a/gdb/remote.c b/gdb/remote.c
> index 8042446ac3d..71ba7da231a 100644
> --- a/gdb/remote.c
> +++ b/gdb/remote.c
> @@ -455,9 +455,6 @@ class remote_state
>  
>    /* The status of the stub support for the various vCont actions.  */
>    vCont_action_support supports_vCont;
> -  /* Whether vCont support was probed already.  This is a workaround
> -     until packet_support is per-connection.  */
> -  bool supports_vCont_probed;
>  
>    /* True if the user has pressed Ctrl-C, but the target hasn't
>       responded to that.  */
> @@ -4951,6 +4948,10 @@ remote_target::start_remote_1 (int from_tty, int extended_p)
>       which later probes to skip.  */
>    remote_query_supported ();
>  
> +  /* Check vCont support and set the remote state's vCont_action_support
> +     attribute.  */
> +  remote_vcont_probe ();
> +
>    /* If the stub wants to get a QAllow, compose one and send it.  */
>    if (m_features.packet_support (PACKET_QAllow) != PACKET_DISABLE)
>      set_permissions ();
> @@ -6467,7 +6468,6 @@ remote_target::remote_vcont_probe ()
>      }
>  
>    m_features.packet_ok (rs->buf, PACKET_vCont);
> -  rs->supports_vCont_probed = true;
>  }
>  
>  /* Helper function for building "vCont" resumptions.  Write a
> @@ -6653,9 +6653,6 @@ remote_target::remote_resume_with_vcont (ptid_t scope_ptid, int step,
>    if (::execution_direction == EXEC_REVERSE)
>      return 0;
>  
> -  if (m_features.packet_support (PACKET_vCont) == PACKET_SUPPORT_UNKNOWN)
> -    remote_vcont_probe ();
> -
>    if (m_features.packet_support (PACKET_vCont) == PACKET_DISABLE)
>      return 0;
>  
> @@ -7189,12 +7186,6 @@ remote_target::remote_stop_ns (ptid_t ptid)
>  	  }
>        }
>  
> -  /* FIXME: This supports_vCont_probed check is a workaround until
> -     packet_support is per-connection.  */
> -  if (m_features.packet_support (PACKET_vCont) == PACKET_SUPPORT_UNKNOWN
> -      || !rs->supports_vCont_probed)
> -    remote_vcont_probe ();
> -
>    if (!rs->supports_vCont.t)
>      error (_("Remote server does not support stopping threads"));
>  
> @@ -14516,9 +14507,6 @@ remote_target::can_do_single_step ()
>      {
>        struct remote_state *rs = get_remote_state ();
>  
> -      if (m_features.packet_support (PACKET_vCont) == PACKET_SUPPORT_UNKNOWN)
> -	remote_vcont_probe ();
> -
>        return rs->supports_vCont.s && rs->supports_vCont.S;
>      }
>    else
> @@ -14827,9 +14815,6 @@ show_range_stepping (struct ui_file *file, int from_tty,
>  bool
>  remote_target::vcont_r_supported ()
>  {
> -  if (m_features.packet_support (PACKET_vCont) == PACKET_SUPPORT_UNKNOWN)
> -    remote_vcont_probe ();
> -
>    return (m_features.packet_support (PACKET_vCont) == PACKET_ENABLE
>  	  && get_remote_state ()->supports_vCont.r);
>  }
> 


  reply	other threads:[~2023-01-23 17:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-21 13:39 [PATCH v4 0/3] Apply fixme notes for multi-target support Christina Schimpe
2022-12-21 13:39 ` [PATCH v4 1/3] gdb: Make global feature array a per-remote target array Christina Schimpe
2022-12-21 14:08   ` Eli Zaretskii
2023-01-23 17:42   ` Pedro Alves
2023-01-30 14:34     ` Schimpe, Christina
2022-12-21 13:39 ` [PATCH v4 2/3] gdb: Add per-remote target variables for memory read and write config Christina Schimpe
2022-12-21 14:13   ` Eli Zaretskii
2023-01-23 17:43   ` Pedro Alves
2023-01-30 14:34     ` Schimpe, Christina
2022-12-21 13:39 ` [PATCH v4 3/3] gdb: Remove workaround for the vCont packet Christina Schimpe
2023-01-23 17:46   ` Pedro Alves [this message]
2023-01-30 14:35     ` Schimpe, Christina
2023-01-16  8:58 ` [PING][PATCH v4 0/3] Apply fixme notes for multi-target support Schimpe, Christina

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=32fd8757-bc08-07d1-bbdd-f6da30137bc8@palves.net \
    --to=pedro@palves.net \
    --cc=aburgess@redhat.com \
    --cc=christina.schimpe@intel.com \
    --cc=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).