From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51153 invoked by alias); 13 Aug 2015 15:22:15 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 51129 invoked by uid 89); 13 Aug 2015 15:22:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 13 Aug 2015 15:22:13 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 953E391E97; Thu, 13 Aug 2015 15:22:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t7DFMAAA001204; Thu, 13 Aug 2015 11:22:11 -0400 Message-ID: <55CCB622.8070306@redhat.com> Date: Thu, 13 Aug 2015 15:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Don Breazeal , gdb-patches@sourceware.org Subject: Re: [PATCH v2 3/5] Extended-remote support for exec event tests References: <1436996979-32350-1-git-send-email-donb@codesourcery.com> <1438298360-29594-1-git-send-email-donb@codesourcery.com> <1438298360-29594-4-git-send-email-donb@codesourcery.com> In-Reply-To: <1438298360-29594-4-git-send-email-donb@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-08/txt/msg00356.txt.bz2 On 07/31/2015 12:19 AM, Don Breazeal wrote: > This patch updates several exec-related tests and some of the > library functions in order to get them running with extended-remote. > There were three changes that were required, as follows: > > In gdb.base/foll-exec.exp, the proc 'zap_session' is used repeatedly > to reset the state of the debugger before the next test. Part of > that procedure is to 'set exec-file'. For remote targets, it is > necessary to also 'set remote exec-file' to achieve the same > effect (and execute the correct binary file in the subsequent test). This assumes local gdbserver testing. This is something that should be done in the target board. Look for exec-file in gdb/testsuite/boards/native-extended-gdbserver.exp. Maybe we should just clean_restart instead ? > > In gdb.base/pie-execl.exp, there is an expect statement with an > expression that is used to match output from both gdb and the > program under debug. For the remote target, this had to be > split into two expressions, using $inferior_spawn_id to match > the output from the program. > > Because I had encountered problems with extended-remote exec events > in non-stop mode in my manual testing, I added non-stop testing to > the non-ldr-exc-[1234].exp tests. In order to set non-stop mode > for remote targets, it is necessary to 'set non-stop on' after gdb > has started, but before it connects to gdbserver. The non-ldr-... > tests call 'clean_restart' in between tests, and it eventually calls > 'gdb_start' which starts gdb and gdbserver and connects them. By > adding a stop mode argument to clean_restart and gdb_start (in > both lib/gdb.exp and boards/native-extended-gdbserver.exp), it was > possible to set non-stop mode for remote targets. Since the > arguments have a default value "all-stop", and only have an effect > when "non-stop" is passed, these changes do not affect any existing > test behavior. I don't think we can do this, because gdb_start is an overridable function (see comment above it). You can instead append set non-stop on to GDBFLAGS. E.g.,: save_vars { GDBFLAGS } { append GDBFLAGS " -ex \"set non-stop $nonstop\"" clean_restart } > diff --git a/gdb/testsuite/gdb.threads/non-ldr-exc-1.exp b/gdb/testsuite/gdb.threads/non-ldr-exc-1.exp > index 69e5cc6..147e7f3 100644 > --- a/gdb/testsuite/gdb.threads/non-ldr-exc-1.exp > +++ b/gdb/testsuite/gdb.threads/non-ldr-exc-1.exp > @@ -28,11 +28,11 @@ if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executab > return -1 > } > > -proc do_test { lock_sched } { > - with_test_prefix "lock-sched$lock_sched" { > +proc do_test { lock_sched stop_mode } { > + with_test_prefix "lock-sched$lock_sched,$stop_mode" { > global executable > > - clean_restart ${executable} > + clean_restart ${executable} $stop_mode > > if ![runto_main] { > return -1 > @@ -48,11 +48,17 @@ proc do_test { lock_sched } { > gdb_test_no_output "set scheduler-locking on" > } > > + if { $stop_mode == "non-stop" } { > + gdb_test "thread 2" "Switching.*" > + } > + > gdb_test "continue" \ > ".*is executing new program.*Breakpoint 1, main.* at .*" \ > "continue over exec" > } > } > > -do_test 0 > -do_test 1 > +do_test 0 "all-stop" > +do_test 1 "all-stop" > +do_test 0 "non-stop" > +do_test 1 "non-stop" Please use foreach. E.g., foreach nonstop {"on" "off"} { foreach schedlock {"on" "off"} { do_test ... } } Note that schedlock on has no effect in non-stop mode. Maybe if !lock_sched && nonstop, we could issue "continue -a" instead of continue. > diff --git a/gdb/testsuite/gdb.threads/non-ldr-exc-2.exp b/gdb/testsuite/gdb.threads/non-ldr-exc-2.exp > index 9386153..748ff11 100644 > --- a/gdb/testsuite/gdb.threads/non-ldr-exc-2.exp > +++ b/gdb/testsuite/gdb.threads/non-ldr-exc-2.exp > @@ -29,18 +29,26 @@ if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executab > return -1 > } > > -proc do_test { lock_sched } { > - with_test_prefix "lock-sched$lock_sched" { > +proc do_test { lock_sched stop_mode } { > + with_test_prefix "lock-sched$lock_sched,$stop_mode" { > global executable > > - clean_restart ${executable} > + clean_restart ${executable} $stop_mode > > if ![runto_main] { > return -1 > } > > gdb_breakpoint [gdb_get_line_number "break-here"] > - gdb_continue_to_breakpoint "break-here" ".* break-here .*" > + gdb_test_multiple "continue" "continue to breakpoint" { > + -re ".*Breakpoint.*break-here.*" { This doesn't expect the prompt, which is going to be racy -- the following gdb_test may fail if this test manages to leave the prompt in the expect buffer. What motivated this change? Thanks, Pedro Alves