From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id EC8303858014 for ; Thu, 18 Nov 2021 22:46:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC8303858014 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-520-tu68MUdIM2WH8Xjf53ckYA-1; Thu, 18 Nov 2021 17:46:40 -0500 X-MC-Unique: tu68MUdIM2WH8Xjf53ckYA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 379CB1922023; Thu, 18 Nov 2021 22:46:39 +0000 (UTC) Received: from f35-m3 (ovpn-112-153.phx2.redhat.com [10.3.112.153]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 78AC4707B6; Thu, 18 Nov 2021 22:46:38 +0000 (UTC) Date: Thu, 18 Nov 2021 15:46:37 -0700 From: Kevin Buettner To: Kevin Buettner via Gdb-patches Cc: Simon Marchi Subject: Re: [PATCH 2/2] Test case for Bug 28308 Message-ID: <20211118154637.4894d3a3@f35-m3> In-Reply-To: <20211109184417.53325769@f35-m3> References: <20211002010054.1546736-1-kevinb@redhat.com> <20211002010054.1546736-3-kevinb@redhat.com> <63bccc55-dcd0-4a3e-77d8-77ea4bd1971d@simark.ca> <20211109184417.53325769@f35-m3> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2021 22:46:45 -0000 On Tue, 9 Nov 2021 18:44:17 -0700 Kevin Buettner via Gdb-patches wrote: > > > +proc do_test {cmd test} { > > > + gdb_test_multiple $cmd $test { > > > +=09-re "$::pat$::inferior_exited_re normally.*$::gdb_prompt $" { > > > +=09 pass $test > > > +=09} > > > +=09-re "Don't know how to run.*$::gdb_prompt $" { > > > +=09 unsupported $test > > > +=09} =20 > >=20 > > Given you used target_can_use_run_cmd at the top, when would this > > unsupported path be taken? =20 >=20 > 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 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=3D"--target_board=3Dnative-extended-gdbserver" \ TESTS=3D"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.gd= b --args testsuite/outputs/gdb.base/dprintf-execution-x-script/dprintf-exec= ution-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-scrip= t.c, line 26. testsuite/gdb.base/dprintf-execution-x-script.gdb:21: Error in sourced comm= and file: Don't know how to run. Try "help target". (gdb) FAIL: gdb.base/dprintf-execution-x-script.exp: load and run script wi= th -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/te= stsuite/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.*?" =20 proc do_test {cmd test} { - gdb_test $cmd "$::pat$::inferior_exited_re normally.*" $test + gdb_test_multiple $cmd $test { +=09-re "$::pat$::inferior_exited_re normally.*$::gdb_prompt $" { +=09 pass $test +=09} +=09-re "Don't know how to run.*$::gdb_prompt $" { +=09 # Even though we bailed out at the beginning of this test case +=09 # for targets which can't use the "run" command, there are +=09 # still targets, e.g. native-extended-gdbserver, which can +=09 # run, but will still print the "Don't know how to run" +=09 # message. In the case of native-extended-gdbserver, it would +=09 # first need to connect to the target in order to run. For +=09 # that particular target, the very first test which attempts +=09 # to use the "run" command from a command line script is +=09 # the one that is unsupported. The other two tests will +=09 # pass because, after reaching the (gdb) prompt, a gdbserver +=09 # is spawned and then connected to. (The command line which +=09 # spawns GDB for this target has a "-iex set +=09 # auto-connect-native-target off" which prevents it from +=09 # attempting to "run" using the native target.) +=09 unsupported $test +=09} + } } =20 # Check output from running script with -x