public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: "Aktemur, Tankut Baris" <tankut.baris.aktemur@intel.com>
To: Bruno Larsen <blarsen@redhat.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [PATCH v2 1/2] gdb/regcache: return REG_UNAVAILABLE if raw_update raises NOT_AVAILABLE_ERROR
Date: Wed, 23 Mar 2022 12:55:27 +0000	[thread overview]
Message-ID: <MWHPR1101MB22711FEF023FF8D76FE21B01C4189@MWHPR1101MB2271.namprd11.prod.outlook.com> (raw)
In-Reply-To: <4a9fc5ba-2053-f0ee-5ef7-450dfaf69d83@redhat.com>

On Wednesday, March 16, 2022 4:19 PM, Bruno Larsen wrote:
> Hello Tankut,

Hi Bruno,

Thanks for your comments.

> On 2/8/22 06:15, Tankut Baris Aktemur via Gdb-patches wrote:
> > In regcache's raw_read, it is possible that 'raw_update' fails with an
> > exception.  Catch this exception and return REG_UNAVAILABLE if the
> > error is of kind NOT_AVAILABLE_ERROR.  This makes clients' lives easier.
> 
> This looks like a good idea for a change. I just have a few small comments.
> 
> Firstly, I'm not sure this change is complex enough to warrant its own commit, since - from
> what I can see - there is no noticeable change in GDB, and the patch itself is quite small,
> it could maybe just be part of patch 2. However, I am not a global maintainer or very
> experienced in patch review, so take this comment with a grain of salt.

My motivation was that 'raw_read' is a central, low-level utility function.
The second patch is about adapting the users.  Let me keep the patches separate
until a global maintainers requests merging them.

> If the commits do
> stay separate, I would add a mention of raw_read in the commit title, otherwise which
> function is returning REG_UNAVAILABLE is not mentioned at all.

Done.

> Also, the commit message is not very descriptive of what could cause the exception in the
> first place, and I feel like that could be good for future reference, but this may just be
> my GDB inexperience speaking.

I added
"This could happen, for instance, if the debugged thread is
already exited and the target cannot fetch its registers."

> >
> > Regression-tested on X86_64-Linux.
> > ---
> >   gdb/regcache.c | 11 ++++++++++-
> >   1 file changed, 10 insertions(+), 1 deletion(-)
> >
> > diff --git a/gdb/regcache.c b/gdb/regcache.c
> > index 00d7a10e289..0379e6a8d0f 100644
> > --- a/gdb/regcache.c
> > +++ b/gdb/regcache.c
> > @@ -598,7 +598,16 @@ enum register_status
> >   readable_regcache::raw_read (int regnum, gdb_byte *buf)
> >   {
> >     gdb_assert (buf != NULL);
> > -  raw_update (regnum);
> > +  try
> > +    {
> > +      raw_update (regnum);
> > +    }
> > +  catch (const gdb_exception_error &ex)
> > +    {
> > +      if (ex.error == NOT_AVAILABLE_ERROR)
> > +	return REG_UNAVAILABLE;
> 
> Lastly, Since this function is returning as if nothing unexpected happened, it should
> probably also set buf to 0 and possibly set m_register_status to REG_UNAVAILABLE - if it
> isn't set by whatever throws the exception.

I modified the patch as below.  The rest of the function handles setting
the contents of buf to 0 and returning m_register_status[regnum], which is
set to REG_UNAVAILABLE in the catch block.

diff --git a/gdb/regcache.c b/gdb/regcache.c
index 00d7a10e289..c57d2e4c345 100644
--- a/gdb/regcache.c
+++ b/gdb/regcache.c
@@ -598,7 +598,17 @@ enum register_status
 readable_regcache::raw_read (int regnum, gdb_byte *buf)
 {
   gdb_assert (buf != NULL);
-  raw_update (regnum);
+  try
+    {
+      raw_update (regnum);
+    }
+  catch (const gdb_exception_error &ex)
+    {
+      if (ex.error != NOT_AVAILABLE_ERROR)
+       throw;
+
+      m_register_status[regnum] = REG_UNAVAILABLE;
+    }

   if (m_register_status[regnum] != REG_VALID)
     memset (buf, 0, m_descr->sizeof_register[regnum]);


Regards
-Baris


Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

  reply	other threads:[~2022-03-23 12:55 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-08  9:15 [PATCH v2 0/2] Querying registers of already-exited processes Tankut Baris Aktemur
2022-02-08  9:15 ` [PATCH v2 1/2] gdb/regcache: return REG_UNAVAILABLE if raw_update raises NOT_AVAILABLE_ERROR Tankut Baris Aktemur
2022-03-16 15:18   ` Bruno Larsen
2022-03-23 12:55     ` Aktemur, Tankut Baris [this message]
2022-02-08  9:15 ` [PATCH v2 2/2] gdb: raise and handle NOT_AVAILABLE_ERROR when accessing frame PC Tankut Baris Aktemur
2022-03-16 17:26   ` Bruno Larsen
2022-03-23 12:55     ` Aktemur, Tankut Baris
2022-03-23 13:34       ` Bruno Larsen
2022-03-24  8:46         ` Aktemur, Tankut Baris
2022-02-22  7:31 ` [PATCH v2 0/2] Querying registers of already-exited processes Aktemur, Tankut Baris
2022-03-07  8:00 ` Aktemur, Tankut Baris
2022-03-23 13:05 ` [PATCH v3 " Tankut Baris Aktemur
2022-03-23 13:05   ` [PATCH v3 1/2] gdb/regcache: return REG_UNAVAILABLE in raw_read if NOT_AVAILABLE_ERROR is seen Tankut Baris Aktemur
2022-03-23 13:05   ` [PATCH v3 2/2] gdb: raise and handle NOT_AVAILABLE_ERROR when accessing frame PC Tankut Baris Aktemur
2022-05-04  7:19   ` [PATCH v3 0/2] Querying registers of already-exited processes Aktemur, Tankut Baris
2022-12-23 17:10     ` Aktemur, Tankut Baris
2023-01-17 20:40       ` Aktemur, Tankut Baris
2023-01-24 10:35       ` Aktemur, Tankut Baris
2023-01-31 20:14       ` Aktemur, Tankut Baris
2023-02-20 13:07       ` Aktemur, Tankut Baris
2023-03-03  7:46       ` Aktemur, Tankut Baris
2023-03-28 13:40       ` Aktemur, Tankut Baris
2023-12-18 14:40   ` [PATCH v4 " Tankut Baris Aktemur
2023-12-18 14:40     ` [PATCH v4 1/2] gdb/regcache: return REG_UNAVAILABLE in raw_read if NOT_AVAILABLE_ERROR is seen Tankut Baris Aktemur
2023-12-18 14:40     ` [PATCH v4 2/2] gdb: raise and handle NOT_AVAILABLE_ERROR when accessing frame PC Tankut Baris Aktemur
2023-12-20 22:00       ` John Baldwin
2023-12-21  6:41         ` Eli Zaretskii
2023-12-27 18:41           ` 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=MWHPR1101MB22711FEF023FF8D76FE21B01C4189@MWHPR1101MB2271.namprd11.prod.outlook.com \
    --to=tankut.baris.aktemur@intel.com \
    --cc=blarsen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    /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).