public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] gdb: make use of SCOPE_EXIT to manage thread executing state
Date: Thu, 23 Dec 2021 11:47:19 +0000 (GMT)	[thread overview]
Message-ID: <20211223114719.92C043858417@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=391c90eea53478a5e96ec88cd713e11909555911

commit 391c90eea53478a5e96ec88cd713e11909555911
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Thu Nov 11 15:17:27 2021 +0000

    gdb: make use of SCOPE_EXIT to manage thread executing state
    
    While working on another patch relating to how GDB manages threads
    executing and resumed state, I spotted the following code in
    record-btrace.c:
    
      executing = tp->executing ();
      set_executing (proc_target, inferior_ptid, false);
    
      id = null_frame_id;
      try
        {
          id = get_frame_id (get_current_frame ());
        }
      catch (const gdb_exception &except)
        {
          /* Restore the previous execution state.  */
          set_executing (proc_target, inferior_ptid, executing);
    
          throw;
        }
    
      /* Restore the previous execution state.  */
      set_executing (proc_target, inferior_ptid, executing);
    
      return id;
    
    I notice that we only catch the exception so we can call
    set_executing, and this is the same call to set_executing that we need
    to perform in the non-exception return path.
    
    This would be much cleaner if we could use SCOPE_EXIT to avoid the
    try/catch, so lets do that.
    
    While cleaning this up, I also applied a similar patch to
    record-full.c, though there's no try/catch in that case, but using
    SCOPE_EXIT makes the code safe if, in the future, we do start throwing
    exceptions.
    
    There should be no user visible changes after this commit.

Diff:
---
 gdb/record-btrace.c | 24 ++++--------------------
 gdb/record-full.c   |  8 +++++---
 2 files changed, 9 insertions(+), 23 deletions(-)

diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
index 3fcfd6a4761..a6ce3db64e5 100644
--- a/gdb/record-btrace.c
+++ b/gdb/record-btrace.c
@@ -1980,9 +1980,6 @@ record_btrace_resume_thread (struct thread_info *tp,
 static struct frame_id
 get_thread_current_frame_id (struct thread_info *tp)
 {
-  struct frame_id id;
-  bool executing;
-
   /* Set current thread, which is implicitly used by
      get_current_frame.  */
   scoped_restore_current_thread restore_thread;
@@ -1998,26 +1995,13 @@ get_thread_current_frame_id (struct thread_info *tp)
      For the former, EXECUTING is true and we're in wait, about to
      move the thread.  Since we need to recompute the stack, we temporarily
      set EXECUTING to false.  */
-  executing = tp->executing ();
+  bool executing = tp->executing ();
   set_executing (proc_target, inferior_ptid, false);
-
-  id = null_frame_id;
-  try
-    {
-      id = get_frame_id (get_current_frame ());
-    }
-  catch (const gdb_exception &except)
+  SCOPE_EXIT
     {
-      /* Restore the previous execution state.  */
       set_executing (proc_target, inferior_ptid, executing);
-
-      throw;
-    }
-
-  /* Restore the previous execution state.  */
-  set_executing (proc_target, inferior_ptid, executing);
-
-  return id;
+    };
+  return get_frame_id (get_current_frame ());
 }
 
 /* Start replaying a thread.  */
diff --git a/gdb/record-full.c b/gdb/record-full.c
index 971c0f568b4..11a9457027c 100644
--- a/gdb/record-full.c
+++ b/gdb/record-full.c
@@ -1249,11 +1249,13 @@ record_full_wait_1 (struct target_ops *ops,
 			  /* Try to insert the software single step breakpoint.
 			     If insert success, set step to 0.  */
 			  set_executing (proc_target, inferior_ptid, false);
-			  reinit_frame_cache ();
+			  SCOPE_EXIT
+			    {
+			      set_executing (proc_target, inferior_ptid, true);
+			    };
 
+			  reinit_frame_cache ();
 			  step = !insert_single_step_breakpoints (gdbarch);
-
-			  set_executing (proc_target, inferior_ptid, true);
 			}
 
 		      if (record_debug)


                 reply	other threads:[~2021-12-23 11:47 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20211223114719.92C043858417@sourceware.org \
    --to=aburgess@sourceware.org \
    --cc=gdb-cvs@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).