public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@redhat.com>
To: gdb-patches@sourceware.org
Cc: Andrew Burgess <aburgess@redhat.com>, tankut.baris.aktemur@intel.com
Subject: [PATCHv2 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp
Date: Tue,  4 Jul 2023 16:22:51 +0100	[thread overview]
Message-ID: <470e7aaaf7e27a36c33083afe412720492a915b1.1688484032.git.aburgess@redhat.com> (raw)
In-Reply-To: <cover.1688484032.git.aburgess@redhat.com>

For *reasons* I was looking at gdb.base/foll-vfork.exp.  This test
script has a proc 'setup_gdb' that could (potentially) fail.  The
setup_gdb proc is called from many places and I, initially, didn't
think that we were checking if setup_gdb had failed or not.

My confusion was because I didn't understand what this tcl construct
did:

  return -code return

this will actually act as a return in the context of a proc's caller,
effectively returning two levels of the call stack.  Neat (I guess).

So it turns out my worries were misplaced, everywhere setup_gdb is
called, if setup_gdb fails then we will (magically) return.

However, I did spot one place where we managed to confuse ourselves
with our cleverness.

In check_vfork_catchpoints, this proc is called to check that GDB is
able to catch vforks or not.  This proc is called early in the test
script, and the intention is that, should this proc fail, we'll mark
the whole test script as unsupported and then move onto the next test
script.

However, check_vfork_catchpoints also uses setup_gdb, and so, if that
call to setup_gdb fails we'll end up returning immediately from
check_vfork_catchpoints, and then continue with the test of _this_
test script, which is not correct.

To fix this I see two choices, one is remove the use of 'return -code
return' from setup_gdb, however, this would require every use of
setup_gdb to then be placed inside:

  if { ![setup_gdb] } {
    return
  }

Or, I can wrap the one call to setup_gdb in check_vfork_catchpoints
and check its return code.

I chose the second option as this is the smaller code change.

There should be no change in what is tested after this commit.
---
 gdb/testsuite/gdb.base/foll-vfork.exp | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.base/foll-vfork.exp b/gdb/testsuite/gdb.base/foll-vfork.exp
index 313afa06324..bdceff0f5de 100644
--- a/gdb/testsuite/gdb.base/foll-vfork.exp
+++ b/gdb/testsuite/gdb.base/foll-vfork.exp
@@ -70,9 +70,15 @@ proc setup_gdb {} {
 
 proc check_vfork_catchpoints {} {
   global gdb_prompt
-  global has_vfork_catchpoints
 
-  setup_gdb
+  # Because setup_gdb uses 'return -code return' which would return to
+  # our caller we need to wrap this call, spot when setup_gdb failed
+  # (with return code 2), and then issue our own 'return -code return'.
+  set code [catch {setup_gdb} string]
+  if { $code == 2 } {
+    unsupported "vfork catchpoints"
+    return -code return
+  }
 
   # Verify that the system supports "catch vfork".
   gdb_test "catch vfork" "Catchpoint \[0-9\]* \\(vfork\\)" "insert first vfork catchpoint"
-- 
2.25.4


  reply	other threads:[~2023-07-04 15:23 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22 13:17 [PATCH 0/8] Some vfork related fixes Andrew Burgess
2023-06-22 13:17 ` [PATCH 1/8] gdb: catch more errors in gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-06-22 13:17 ` [PATCH 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-06-22 13:17 ` [PATCH 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-06-28  8:47   ` Aktemur, Tankut Baris
2023-07-04 15:24     ` Andrew Burgess
2023-06-22 13:17 ` [PATCH 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-06-22 13:17 ` [PATCH 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-06-22 13:17 ` [PATCH 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-04 15:22 ` [PATCHv2 0/8] Some vfork related fixes Andrew Burgess
2023-07-04 15:22   ` Andrew Burgess [this message]
2023-07-04 15:22   ` [PATCHv2 2/8] gdb: don't restart vfork parent while waiting for child to finish Andrew Burgess
2023-07-05 10:08     ` Aktemur, Tankut Baris
2023-07-04 15:22   ` [PATCHv2 3/8] gdb: fix an issue with vfork in non-stop mode Andrew Burgess
2023-07-04 15:22   ` [PATCHv2 4/8] gdb, infrun: refactor part of `proceed` into separate function Andrew Burgess
2023-07-04 15:22   ` [PATCHv2 5/8] gdb: don't resume vfork parent while child is still running Andrew Burgess
2023-07-18 20:42     ` Simon Marchi
2023-07-21  9:47       ` Andrew Burgess
2023-07-23  8:53       ` Andrew Burgess
2023-08-16 14:02         ` Andrew Burgess
2023-08-17  6:36           ` Tom de Vries
2023-08-17  7:01             ` Tom de Vries
2023-08-17  8:06               ` Tom de Vries
2023-08-17  8:22                 ` Tom de Vries
2023-07-04 15:22   ` [PATCHv2 6/8] gdb/testsuite: expand gdb.base/foll-vfork.exp Andrew Burgess
2023-07-05 11:22     ` Aktemur, Tankut Baris
2023-07-04 15:22   ` [PATCHv2 7/8] gdb/testsuite: remove use of sleep from gdb.base/foll-vfork.exp Andrew Burgess
2023-07-04 15:22   ` [PATCHv2 8/8] gdb: additional debug output in infrun.c and linux-nat.c Andrew Burgess
2023-07-05 11:30   ` [PATCHv2 0/8] Some vfork related fixes Aktemur, Tankut Baris
2023-07-17  8:53     ` Andrew Burgess

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=470e7aaaf7e27a36c33083afe412720492a915b1.1688484032.git.aburgess@redhat.com \
    --to=aburgess@redhat.com \
    --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).