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: linkBe 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).