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 25/26] gdbserver: refuse null argument in regcache::supply_regblock
Date: Thu, 21 Dec 2023 23:54:48 -0500	[thread overview]
Message-ID: <1906794c-8f34-4d6e-9b41-be14ce74e96e@simark.ca> (raw)
In-Reply-To: <39a4774140afc2f7253756971398fc2cabceb289.1677582745.git.tankut.baris.aktemur@intel.com>



On 2023-02-28 06:28, Tankut Baris Aktemur via Gdb-patches wrote:
> The regcache::supply_regblock method implements two different
> behaviors based on whether its 'buf' argument is null.  The null
> behavior is used only in tracepoint.cc.  Refuse the null pointer
> argument and use the 'discard' method to obtain that second behavior.
> 
> Note that the original code resets register statuses to
> REG_UNAVAILABLE, but 'discard' sets them to REG_UNKNOWN.  For the
> current purposes of resetting the regcache, the difference does not
> seem to be important.

Ah, glad to see this, it matches one of my comment on an earlier patch
(and as you can see, I read patch series in a very linear way with no
lookahead).

In the spots inside the in-process agent, the regcache doesn't even
track statuses, so it doesn't make a difference indeed.

> diff --git a/gdbserver/tracepoint.cc b/gdbserver/tracepoint.cc
> index 9833e7c3b0f..9622d53cd82 100644
> --- a/gdbserver/tracepoint.cc
> +++ b/gdbserver/tracepoint.cc
> @@ -4707,7 +4707,7 @@ get_context_regcache (struct tracepoint_hit_ctx *ctx)
>  	{
>  	  fctx->regcache_initted = 1;
>  	  fctx->regcache.initialize (ipa_tdesc, fctx->regspace);
> -	  fctx->regcache.supply_regblock (nullptr);
> +	  fctx->regcache.discard ();
>  	  supply_fast_tracepoint_registers (&fctx->regcache, fctx->regs);

I think the call to discard is pointless.  The call to discard does (and
should) pretty much bring the regcache back to its state just after
initialization.  In this case, it was initialized at the line just before.

>  	}
>        regcache = &fctx->regcache;
> @@ -4722,7 +4722,7 @@ get_context_regcache (struct tracepoint_hit_ctx *ctx)
>  	{
>  	  sctx->regcache_initted = 1;
>  	  sctx->regcache.initialize (ipa_tdesc, sctx->regspace);
> -	  sctx->regcache.supply_regblock (nullptr);
> +	  sctx->regcache.discard ();

Same here.

>  	  /* Pass down the tracepoint address, because REGS doesn't
>  	     include the PC, but we know what it must have been.  */
>  	  supply_static_tracepoint_registers (&sctx->regcache,
> @@ -5179,8 +5179,8 @@ fetch_traceframe_registers (int tfnum, struct regcache *regcache, int regnum)
>    dataptr = traceframe_find_regblock (tframe, tfnum);
>    if (dataptr == NULL)
>      {
> -      /* Mark registers unavailable.  */
> -      regcache->supply_regblock (nullptr);
> +      /* Wipe out the cache.  */
> +      regcache->discard ();

So, I think this is a spot where you would actually want to make the
registers REG_UNAVAILABLE.  We are filling a regcache meant to represent
the registers that were collected when hitting a given tracepoint.  If
traceframe_find_regblock returns nullptr, I guess it means that we
didn't collect the registers.  So all registers are unavailable.

In practice, it won't make a difference, because that regcache is then
fed to registers_to_string, which will have the same behavior for
REG_UNAVAILABLE and REG_UNKNOWN.  But if you want to be accurate, I
think that REG_UNAVAILABLE makes more sense here.

Simon

  reply	other threads:[~2023-12-22  4:54 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
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 [this message]
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=1906794c-8f34-4d6e-9b41-be14ce74e96e@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).