Re: [PATCH v3 5/8] gdbserver: Transmit target description ID in thread list and stop reply

[Andrew Burgess <aburgess@redhat.com>]

Thiago Jung Bauermann via Gdb-patches <gdb-patches@sourceware.org>
writes:

> Now that an inferior thread can have a different target description than
> its process, there needs to be a way to communicate this target
> description to GDB.  So add the concept of a target description ID to the
> remote protocol, which is used to reference them and allows them to be
> transferred only once over the wire.
>
> The ID is an unsigned integer, and is sent in the 'T AA n1:r1;n2:r2;...'
> stop reply packet as a new 'n:r' pair, where n is "tdesc" and "r" is an
> unsigned integer containing the ID.
>
> It is also sent in the threads list XML in the response of a
> qXfer:threads:read request.  The ID is sent as a new "tdesc" attribute of
> the <thread> node.
>
> To request the target description XML of a given ID, GDB sends the
> qXfer:features:read request with "target-id-%u.xml" as the annex, where %u
> is the target description ID.

Luis already commented that in some locations the ID is hex, while in
others it is not explicitly stated if the value is hex or decimal.  I'd
like to second that feedback, and suggest that we pick one, and use that
consistently throughout.

My thinking is that it will be easier to understand remote packet traces
if target descriptions are requested using an ID in the safe format as
was sent to GDB, and if IDs in different packets match up.

Thus, I would suggest we switch to using 'target-id-%x.xml' here, and
send the ID as hex in the threads reply packet.

Additionally, I think it would be worth adding a new feature to the
qSupported packet, maybe 'per-thread-tdesc'.  With this added, GDB would
be able to tell gdbserver that it supports this feature, and gdbserver
will be able to confirm that the feature is supported.

I'm not 100% sure what we'd want to do if it turns out GDB doesn't
support the feature?  Is it better to push on with GDB using the wrong
target description?  Or would it be better if gdbserver exits with an
error suggesting the GDB needs updating?  In some ways, _what_ we do
doesn't really matter to me, but I think having the feature will allow
us to pick a suitable error handling solution later if needed.

I'd be happy if adding the feature was done as a separate patch in this
series, but I do think it should be part of this series.

>
> Suggested-By: Simon Marchi <simon.marchi@efficios.com>
> ---
>  gdb/doc/gdb.texinfo       | 27 ++++++++++++++++---
>  gdbserver/remote-utils.cc | 57 +++++++++++++++++++++++++++++++++++++++
>  gdbserver/remote-utils.h  |  9 +++++++
>  gdbserver/server.cc       | 17 ++++++++++--
>  gdbserver/server.h        |  4 +++
>  5 files changed, 109 insertions(+), 5 deletions(-)
>
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 9c0018ea5c14..fbf7e59853b5 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -42030,6 +42030,10 @@ the stopped thread, as specified in @ref{thread-id syntax}.
>  If @var{n} is @samp{core}, then @var{r} is the hexadecimal number of
>  the core on which the stop event was detected.
>  
> +@item
> +If @var{n} is @samp{tdesc}, then @var{r} is the hexadecimal number of
> +the target description ID (@pxref{Target Description ID}).
> +
>  @item
>  If @var{n} is a recognized @dfn{stop reason}, it describes a more
>  specific event that stopped the target.  The currently defined stop
> @@ -46546,7 +46550,7 @@ the following structure:
>  @smallexample
>  <?xml version="1.0"?>
>  <threads>
> -    <thread id="id" core="0" name="name">
> +    <thread id="id" core="0" name="name" tdesc="0">
>      ... description ...
>      </thread>
>  </threads>
> @@ -46556,8 +46560,10 @@ Each @samp{thread} element must have the @samp{id} attribute that
>  identifies the thread (@pxref{thread-id syntax}).  The
>  @samp{core} attribute, if present, specifies which processor core
>  the thread was last executing on.  The @samp{name} attribute, if
> -present, specifies the human-readable name of the thread.  The content
> -of the of @samp{thread} element is interpreted as human-readable
> +present, specifies the human-readable name of the thread.  The
> +@samp{tdesc} attribute, if present, specifies the target description
> +ID of the thread (@pxref{Target Description ID}).  The content of
> +the @samp{thread} element is interpreted as human-readable
>  auxiliary information.  The @samp{handle} attribute, if present,
>  is a hex encoded representation of the thread handle.
>  
> @@ -46767,6 +46773,8 @@ descriptions are accurate, and that @value{GDBN} understands them.
>  target descriptions.  @xref{Expat}.
>  
>  @menu
> +* Target Description ID::           Referencing different descriptions in the
> +                                    remote protocol.
>  * Retrieving Descriptions::         How descriptions are fetched from a target.
>  * Target Description Format::       The contents of a target description.
>  * Predefined Target Types::         Standard types available for target
> @@ -46775,6 +46783,14 @@ target descriptions.  @xref{Expat}.
>  * Standard Target Features::        Features @value{GDBN} knows about.
>  @end menu
>  
> +@node Target Description ID
> +@section Target Description ID
> +
> +In cases where a remote target supports threads having different
> +target descriptions than their parent process, the remote protocol
> +assigns a non-negative integer to each target description to reference
> +it in the communication between the host and the target.

I think this should be reworded slightly.  I would prefer that it be
made clear that it is the remote target that is responsible for
assigning the ID numbers for target descriptions.

It would also be nice if there were some cross references from this
section to the other places in the manual where we discuss
sending/receiving the ID number.

Finally, I wonder if it might make sense to add something like:

  @cindex Target Description IDs

to every place where we discuss these ID's, then there will be an index
entry that links all the places together?

> +
>  @node Retrieving Descriptions
>  @section Retrieving Descriptions
>  
> @@ -46787,6 +46803,11 @@ qXfer}).  The @var{annex} in the @samp{qXfer} packet will be
>  XML document, of the form described in @ref{Target Description
>  Format}.
>  
> +If target description IDs are being used (@pxref{Target Description ID}),
> +@value{GDBN} can retrieve a target description with a given ID by using
> +@samp{target-id-ID.xml} as the @var{annex}, where @var{ID} is the
> +non-negative integer identifier of the desired target description.
> +
>  Alternatively, you can specify a file to read for the target description.
>  If a file is set, the target will not be queried.  The commands to
>  specify a file are:
> diff --git a/gdbserver/remote-utils.cc b/gdbserver/remote-utils.cc
> index 80310bc2c709..baff899307cc 100644
> --- a/gdbserver/remote-utils.cc
> +++ b/gdbserver/remote-utils.cc
> @@ -1049,6 +1049,53 @@ outreg (struct regcache *regcache, int regno, char *buf)
>    return buf;
>  }
>  
> +/* See remote-utils.h.  */
> +
> +unsigned int
> +get_tdesc_rsp_id (const target_desc *tdesc)
> +{
> +  client_state &cs = get_client_state ();
> +  unsigned int i;
> +
> +  for (i = 0; i < cs.tdescs.size (); i++)
> +    if (cs.tdescs[i] == tdesc)
> +      return i;
> +
> +  cs.tdescs.push_back (tdesc);
> +
> +  return i;
> +}
> +
> +/* See remote-utils.h.  */
> +
> +const target_desc *
> +get_tdesc_from_rsp_id (unsigned int id)
> +{
> +  client_state &cs = get_client_state ();
> +
> +  if (id >= cs.tdescs.size ())
> +    return nullptr;
> +
> +  return cs.tdescs[id];
> +}
> +
> +/* Return the ID as used in the remote protocol for the target descriptor of the
> +   given PTID.  */
> +
> +static unsigned int
> +get_tdesc_rsp_id (ptid_t ptid)
> +{
> +  const thread_info *thread = find_thread_ptid (ptid);
> +  const target_desc *tdesc;
> +
> +  if (thread == nullptr)
> +    tdesc = find_process_pid (ptid.pid ())->tdesc;
> +  else
> +    tdesc = get_thread_target_desc (thread);
> +
> +  return get_tdesc_rsp_id (tdesc);
> +}
> +
>  void
>  prepare_resume_reply (char *buf, ptid_t ptid, const target_waitstatus &status)
>  {
> @@ -1241,6 +1288,16 @@ prepare_resume_reply (char *buf, ptid_t ptid, const target_waitstatus &status)
>  	    buf += strlen (buf);
>  	    current_process ()->dlls_changed = false;
>  	  }
> +
> +	if (current_thread->tdesc != nullptr
> +	    && current_thread->tdesc != current_process ()->tdesc)
> +	  {
> +	    sprintf (buf, "tdesc:");
> +	    buf += strlen (buf);
> +	    sprintf (buf, "%x", get_tdesc_rsp_id (ptid));
> +	    strcat (buf, ";");
> +	    buf += strlen (buf);
> +	  }
>        }
>        break;
>      case TARGET_WAITKIND_EXITED:
> diff --git a/gdbserver/remote-utils.h b/gdbserver/remote-utils.h
> index cb2d6c346c99..61ef80b4dad7 100644
> --- a/gdbserver/remote-utils.h
> +++ b/gdbserver/remote-utils.h
> @@ -75,4 +75,13 @@ int relocate_instruction (CORE_ADDR *to, CORE_ADDR oldloc);
>  
>  void monitor_output (const char *msg);
>  
> +/* Return the ID as used in the remote protocol for the given target
> +   descriptor.  */
> +
> +unsigned int get_tdesc_rsp_id (const target_desc *tdesc);
> +
> +/* Return the target description corresponding to the remote protocol ID.  */

This comment should explain what happens if the ID is invalid
(i.e. returns nullptr).

> +
> +const target_desc *get_tdesc_from_rsp_id (unsigned int id);
> +
>  #endif /* GDBSERVER_REMOTE_UTILS_H */
> diff --git a/gdbserver/server.cc b/gdbserver/server.cc
> index 21fb51a45d16..2d1062f98468 100644
> --- a/gdbserver/server.cc
> +++ b/gdbserver/server.cc
> @@ -976,7 +976,15 @@ handle_general_set (char *own_buf)
>  static const char *
>  get_features_xml (const char *annex)
>  {
> -  const struct target_desc *desc = current_target_desc ();
> +  const struct target_desc *desc;
> +  unsigned int id;
> +
> +  if (strcmp (annex, "target.xml") == 0)
> +    desc = current_target_desc ();
> +  else if (sscanf (annex, "target-id-%u.xml", &id) == 1)
> +    desc = get_tdesc_from_rsp_id (id);
> +  else
> +    desc = nullptr;
>  
>    /* `desc->xmltarget' defines what to return when looking for the
>       "target.xml" file.  Its contents can either be verbatim XML code

This comment could be updated to replace '"target.xml"' with 'target
description' now that we handle multiple annex names.

There's a second reference toe "target.xml" at the end of the comment,
which can also be removed with a little rewording.

Thanks,
Andrew

> @@ -986,7 +994,7 @@ get_features_xml (const char *annex)
>       This variable is set up from the auto-generated
>       init_registers_... routine for the current target.  */
>  
> -  if (strcmp (annex, "target.xml") == 0)
> +  if (desc != nullptr)
>      {
>        const char *ret = tdesc_get_features_xml (desc);
>  
> @@ -1664,6 +1672,11 @@ handle_qxfer_threads_worker (thread_info *thread, struct buffer *buffer)
>    if (name != NULL)
>      buffer_xml_printf (buffer, " name=\"%s\"", name);
>  
> +  if (thread->tdesc != nullptr
> +      && thread->tdesc != get_thread_process (thread)->tdesc)
> +    buffer_xml_printf (buffer, " tdesc=\"%u\"",
> +		       get_tdesc_rsp_id (thread->tdesc));
> +
>    if (handle_status)
>      {
>        char *handle_s = (char *) alloca (handle_len * 2 + 1);
> diff --git a/gdbserver/server.h b/gdbserver/server.h
> index 7997d1a32e6e..58be5027795b 100644
> --- a/gdbserver/server.h
> +++ b/gdbserver/server.h
> @@ -193,6 +193,10 @@ struct client_state
>    /* If true, memory tagging features are supported.  */
>    bool memory_tagging_feature = false;
>  
> +  /* The target descriptions that have been communicated to the client.  The
> +     index of a target description in this vector is the ID used to reference it
> +     in the remote protocol.  */
> +  std::vector<const target_desc *> tdescs;
>  };
>  
>  client_state &get_client_state ();