public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH 21/26] gdbserver: use REG_UNKNOWN for a regcache's register statuses
Date: Thu, 21 Dec 2023 23:32:34 -0500	[thread overview]
Message-ID: <8aa2a7c6-4966-4278-a450-f0ede240012c@simark.ca> (raw)
In-Reply-To: <1fcffbf8ffd62b07585baebff38b66f10ec0a112.1677582745.git.tankut.baris.aktemur@intel.com>



On 2023-02-28 06:28, Tankut Baris Aktemur via Gdb-patches wrote:
> When a regcache is initialized, the values of registers are not
> fetched yet.  Thus, initialize the register statuses to REG_UNKNOWN
> instead of REG_UNAVAILABLE, because the latter rather means "we
> attempted to fetch but could not obtain the value".
> 
> The definitions of the reg status enums (from
> gdbsupport/common-regcache.h) as a reminder:
> 
>     /* The register value is not in the cache, and we don't know yet
>        whether it's available in the target (or traceframe).  */
>     REG_UNKNOWN = 0,
> 
>     /* The register value is valid and cached.  */
>     REG_VALID = 1,
> 
>     /* The register value is unavailable.  E.g., we're inspecting a
>        traceframe, and this register wasn't collected.  Note that this
>        "unavailable" is different from saying the register does not
>        exist in the target's architecture --- in that case, the target
>        should have given us a target description that does not include
>        the register in the first place.  */
>     REG_UNAVAILABLE = -1
> 
> Similarly, when the regcache is invalidated, change all the statuses
> back to REG_UNKNOWN.

That makes sense to me.

> ---
>  gdbserver/regcache.cc | 16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/gdbserver/regcache.cc b/gdbserver/regcache.cc
> index 09ea58bdbd6..2befb30e337 100644
> --- a/gdbserver/regcache.cc
> +++ b/gdbserver/regcache.cc
> @@ -64,9 +64,17 @@ regcache::fetch ()
>        switch_to_thread (this->thread);
>  
>        /* Invalidate all registers, to prevent stale left-overs.  */
> -      memset (register_status, REG_UNAVAILABLE, tdesc->reg_defs.size ());
> +      discard ();
>        fetch_inferior_registers (this, -1);
>        registers_fetched = true;
> +
> +      /* Make sure that the registers that could not be fetched are
> +	 now unavailable.  */
> +      for (int i = 0; i < tdesc->reg_defs.size (); ++i)
> +	{
> +	  if (register_status[i] == REG_UNKNOWN)
> +	    set_register_status (i, REG_UNAVAILABLE);
> +	}

The braces are not needed.

But is it really needed to do this?  Unavailable is only meaningful for
tracing, in a regcache that is the result of tracepoint collection.  For
a regcache created by reading registers from the target, I don't think
that setting statuses to unavailable makes sense.

Also, if asking the target to fetch all registers, why would some
registers still be unknown?  It's the target that provides the target
description, it's supposed to only include registers that exist (like
the comment on top of REG_UNAVAILABLE says).  So it should be able to
read them all.  In other words, I think this loop should be asserting
that all statuses are REG_VALID.

But then for the tracing case, I wonder who sets the statuses to
REG_UNAVAILABLE for those statuses that should really be
REG_UNAVAILABLE.  From what I can see, all regcaches used on the tracing
code paths use the regcache constructor with 2 arguments, which means
regcaches that don't track the status of registers
(regcache::register_status is nullptr).  So... now that you changed
regcache to use REG_UNKNOWN by default, is REG_UNAVAILABLE really
used in GDBserver?

I noticed that do_action_at_tracepoint has a comment that says "Collect
all registers for now.".  I guess that if it didn't collect all
registers, this would be a spot that would explicitly set some registers
to REG_UNAVAILABLE.

I see that for fast tracepoints, for instance
supply_fast_tracepoint_registers in linux-amd64-ipa.cc, we supply a
fixed set of registers.  Clearly, these are not all the registers that
an amd64 machine could have.  But it just writes a register buffer that
ends up in the trace, there doesn't seem to be a way to communicate
which registers were collected and which weren't.  When we create a new
regcache to read these registers, when handling the 'g' packet in
server.cc, there's no way to know which individual registers were
collected and which weren't.

Simon

  reply	other threads:[~2023-12-22  4:32 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 11:27 [PATCH 00/26] gdbserver: refactor regcache and allow gradually populating Tankut Baris Aktemur
2023-02-28 11:27 ` [PATCH 01/26] gdbserver: convert init_register_cache into regcache::initialize Tankut Baris Aktemur
2023-12-21 20:12   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 02/26] gdbserver: convert new_register_cache into a regcache constructor Tankut Baris Aktemur
2023-12-21 20:19   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 03/26] gdbserver: by-pass regcache to access tdesc only Tankut Baris Aktemur
2023-12-21 20:22   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 04/26] gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache Tankut Baris Aktemur
2023-12-21 20:24   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 05/26] gdbserver: add a pointer to the owner thread in regcache Tankut Baris Aktemur
2023-12-21 20:28   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 06/26] gdbserver: turn part of get_thread_regcache into regcache::fetch Tankut Baris Aktemur
2023-12-21 20:48   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 07/26] gdbserver: convert regcache_cpy into regcache::copy_from Tankut Baris Aktemur
2023-12-21 20:50   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 08/26] gdbserver: convert free_register_cache into a destructor of regcache Tankut Baris Aktemur
2023-12-21 20:57   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 09/26] gdbserver: extract out regcache::invalidate and regcache::discard Tankut Baris Aktemur
2023-12-21 21:08   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 10/26] gdbserver: convert registers_to_string into regcache::registers_to_string Tankut Baris Aktemur
2023-12-21 21:13   ` Simon Marchi
2023-12-21 21:19     ` Simon Marchi
2023-02-28 11:28 ` [PATCH 11/26] gdbserver: convert registers_from_string into regcache::registers_from_string Tankut Baris Aktemur
2023-02-28 11:28 ` [PATCH 12/26] gdbserver: convert supply_regblock to regcache::supply_regblock Tankut Baris Aktemur
2023-12-21 21:23   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 13/26] gdbserver: convert register_data into regcache::register_data Tankut Baris Aktemur
2023-12-21 21:26   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 14/26] gdbserver: introduce and use regcache::set_register_status Tankut Baris Aktemur
2023-12-21 21:30   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 15/26] gdbserver: check for nullptr condition in regcache::get_register_status Tankut Baris Aktemur
2023-12-21 21:32   ` Simon Marchi
2023-12-21 21:34   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 16/26] gdbserver: boolify regcache fields Tankut Baris Aktemur
2023-12-22  3:20   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 17/26] gdbserver: rename regcache's registers_valid to registers_fetched Tankut Baris Aktemur
2023-12-22  3:23   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 18/26] gdbsupport: fix a typo in a comment in common-regcache.h Tankut Baris Aktemur
2023-12-22  3:24   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 19/26] gdbserver: fix the declared type of register_status in regcache Tankut Baris Aktemur
2023-12-22  3:35   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 20/26] gdbserver: make some regcache fields private Tankut Baris Aktemur
2023-12-22  3:39   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 21/26] gdbserver: use REG_UNKNOWN for a regcache's register statuses Tankut Baris Aktemur
2023-12-22  4:32   ` Simon Marchi [this message]
2023-02-28 11:28 ` [PATCH 22/26] gdbserver: zero-out register values in regcache-discard Tankut Baris Aktemur
2023-12-22  4:36   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 23/26] gdbserver: set register statuses in registers_from_string Tankut Baris Aktemur
2023-12-22  4:40   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 24/26] gdbserver: return tracked register status in regcache_raw_read_unsigned Tankut Baris Aktemur
2023-12-22  4:42   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 25/26] gdbserver: refuse null argument in regcache::supply_regblock Tankut Baris Aktemur
2023-12-22  4:54   ` Simon Marchi
2023-02-28 11:28 ` [PATCH 26/26] gdbserver: allow gradually populating and selectively storing a regcache Tankut Baris Aktemur
2023-12-22 16:25   ` Simon Marchi
2023-03-07 20:39 ` [PATCH 00/26] gdbserver: refactor regcache and allow gradually populating Tom Tromey
2023-03-13 14:33   ` Aktemur, Tankut Baris
2023-03-28 13:42 ` Aktemur, Tankut Baris
2023-06-20 12:58 ` Aktemur, Tankut Baris

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=8aa2a7c6-4966-4278-a450-f0ede240012c@simark.ca \
    --to=simark@simark.ca \
    --cc=gdb-patches@sourceware.org \
    --cc=tankut.baris.aktemur@intel.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).