public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Kevin Buettner via Gdb-patches <gdb-patches@sourceware.org>
Cc: Simon Marchi <simark@simark.ca>
Subject: Re: [PATCH 2/2] Test case for Bug 28308
Date: Thu, 18 Nov 2021 15:46:37 -0700	[thread overview]
Message-ID: <20211118154637.4894d3a3@f35-m3> (raw)
In-Reply-To: <20211109184417.53325769@f35-m3>

On Tue, 9 Nov 2021 18:44:17 -0700
Kevin Buettner via Gdb-patches <gdb-patches@sourceware.org> wrote:

> > > +proc do_test {cmd test} {
> > > +    gdb_test_multiple $cmd $test {
> > > +	-re "$::pat$::inferior_exited_re normally.*$::gdb_prompt $" {
> > > +	    pass $test
> > > +	}
> > > +	-re "Don't know how to run.*$::gdb_prompt $" {
> > > +	    unsupported $test
> > > +	}    
> > 
> > Given you used target_can_use_run_cmd at the top, when would this
> > unsupported path be taken?  
> 
> It won't be.  I've rewritten it to use gdb_test instead.

It turns out that I was wrong about this; native-extended-gdbserver
needs the unsupported path as explained by the (pushed) commit below:

From 625e7822339cf944300bf9cc044f6a469a3e616d Mon Sep 17 00:00:00 2001
From: Kevin Buettner <kevinb@redhat.com>
Date: Thu, 18 Nov 2021 15:06:01 -0700
Subject: [PATCH] dprintf-execution-x-script.exp: Adjust test for
 native-extended-gdbserver

Without this commit, doing...

make check RUNTESTFLAGS="--target_board=native-extended-gdbserver" \
           TESTS="gdb.base/dprintf-execution-x-script.exp"

...will show one failure.

Here's a snippet from gdb.log showing the circumstances - I've trimmed
the paths for readability:

builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 -iex set width 0 -iex set auto-connect-native-target off -iex set sysroot -ex set height unlimited -x testsuite/gdb.base/dprintf-execution-x-script.gdb --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script
...
Reading symbols from testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-execution-x-script...
Dprintf 1 at 0x40116e: file testsuite/gdb.base/dprintf-execution-x-script.c, line 38.
Breakpoint 2 at 0x40113a: file testsuite/gdb.base/dprintf-execution-x-script.c, line 26.
testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced command file:
Don't know how to run.  Try "help target".
(gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script with -x
...
GNU gdb (GDB) 12.0.50.20211118-git
Copyright (C) 2021 Free Software Foundation, Inc.
...
(gdb) set height 0
(gdb) set width 0
(gdb) builtin_spawn gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
...
[Tests after this point will pass.]

Note that the command which spawns gdb prevents the gdb script from
using the native target via "-iex set auto-connect-native-target off".

Moreover, the script in question contains a "run" command, so GDB
doesn't know how to run (since it's prevented from using the native
target and no alternate "target" command has been issued.  But, once
GDB finishes starting up, the test will spawn a gdbserver and then
connect to it.  The other (two) tests after this point both pass.

I've fixed this by using gdb_test_multiple instead of gdb_test.
When a "Don't know how to run message" is received, the test is
unsupported.

I've also added a comment explaining the reason for needing to check
for "Don't know how to run" despite bailing out at the top of the test
via:

  if ![target_can_use_run_cmd] {
      return 0
  }

diff --git a/gdb/testsuite/gdb.base/dprintf-execution-x-script.exp b/gdb/testsuite/gdb.base/dprintf-execution-x-script.exp
index 9133af752be..99caf359e41 100644
--- a/gdb/testsuite/gdb.base/dprintf-execution-x-script.exp
+++ b/gdb/testsuite/gdb.base/dprintf-execution-x-script.exp
@@ -67,7 +67,28 @@ set b "Breakpoint ., inc_vi"
 set pat "${d}0.*?$b.*?${d}1.*?$b.*?${d}2.*?$b.*?"
 
 proc do_test {cmd test} {
-    gdb_test $cmd "$::pat$::inferior_exited_re normally.*" $test
+    gdb_test_multiple $cmd $test {
+	-re "$::pat$::inferior_exited_re normally.*$::gdb_prompt $" {
+	    pass $test
+	}
+	-re "Don't know how to run.*$::gdb_prompt $" {
+	    # Even though we bailed out at the beginning of this test case
+	    # for targets which can't use the "run" command, there are
+	    # still targets, e.g. native-extended-gdbserver, which can
+	    # run, but will still print the "Don't know how to run"
+	    # message.  In the case of native-extended-gdbserver, it would
+	    # first need to connect to the target in order to run.  For
+	    # that particular target, the very first test which attempts
+	    # to use the "run" command from a command line script is
+	    # the one that is unsupported.  The other two tests will
+	    # pass because, after reaching the (gdb) prompt, a gdbserver
+	    # is spawned and then connected to.  (The command line which
+	    # spawns GDB for this target has a "-iex set
+	    # auto-connect-native-target off" which prevents it from
+	    # attempting to "run" using the native target.)
+	    unsupported $test
+	}
+    }
 }
 
 # Check output from running script with -x


  reply	other threads:[~2021-11-18 22:46 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-02  1:00 [PATCH 0/2] Fix PR 28308 - dprintf breakpoints not working when run from script Kevin Buettner
2021-10-02  1:00 ` [PATCH 1/2] " Kevin Buettner
2021-11-05 16:05   ` Simon Marchi
2021-11-10  3:34     ` Kevin Buettner
2021-11-16 20:18       ` Tom Tromey
2021-11-18 18:34         ` Kevin Buettner
2021-10-02  1:00 ` [PATCH 2/2] Test case for Bug 28308 Kevin Buettner
2021-11-05 16:21   ` Simon Marchi
2021-11-10  1:44     ` Kevin Buettner
2021-11-18 22:46       ` Kevin Buettner [this message]
2021-10-19  9:30 ` [PATCH 0/2] Fix PR 28308 - dprintf breakpoints not working when run from script Kevin Buettner
2021-11-02 19:09 ` Kevin Buettner

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=20211118154637.4894d3a3@f35-m3 \
    --to=kevinb@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /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).