This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v2 3/5] Extended-remote support for exec event tests
- From: Pedro Alves <palves at redhat dot com>
- To: Don Breazeal <donb at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Thu, 13 Aug 2015 16:22:10 +0100
- Subject: Re: [PATCH v2 3/5] Extended-remote support for exec event tests
- Authentication-results: sourceware.org; auth=none
- References: <1436996979-32350-1-git-send-email-donb at codesourcery dot com> <1438298360-29594-1-git-send-email-donb at codesourcery dot com> <1438298360-29594-4-git-send-email-donb at codesourcery dot com>
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