old-cross-binutils/gdb/testsuite/gdb.threads/non-ldr-exc-3.exp
Pedro Alves d15dcecdee Fix gdb.threads/non-ldr-exc-3.exp race
gdb.threads/non-ldr-exc-3.exp is sometimes failing like this:

 [Switching to Thread 6831.6832]

 Breakpoint 2, thread_execler (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/non-ldr-exc-3.c:41
 41        if (execl (image, image, argv1, NULL) == -1) /* break-here */
 PASS: gdb.threads/non-ldr-exc-3.exp: lock-sched=on,non-stop=off: continue to breakpoint
 (gdb) set scheduler-locking on
 (gdb) FAIL: gdb.threads/non-ldr-exc-3.exp: lock-sched=on,non-stop=off: set scheduler-locking on

The problem is that the gdb_test_multiple is missing the prompt
anchor.  The problem was introduced by 2fd33e9448.  This reverts the
hunk that introduced the problem, reverting back to
gdb_continue_to_breakpoint.

gdb/testsuite/ChangeLog:
2015-09-15  Pedro Alves  <palves@redhat.com>

	* gdb.threads/non-ldr-exc-3.exp (do_test): Use
	gdb_continue_to_breakpoint instead of gdb_test_multiple.
2015-09-15 17:01:59 +01:00

75 lines
2.2 KiB
Text

# Copyright 2009-2015 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Test that when a thread other than the main thread execs, we follow
# through to the new incarnation of the main thread, even if the main
# thread had already exited before the exec. This differs from
# non-ldr-exc-2.exp in that we have more than two threads in the
# program when the exec happens.
# No exec event support in the remote protocol.
if { [is_remote target] } then {
continue
}
standard_testfile
set executable ${testfile}
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
return -1
}
proc do_test { lock_sched nonstop } {
with_test_prefix "lock-sched=$lock_sched,non-stop=$nonstop" {
global executable
save_vars { GDBFLAGS } {
append GDBFLAGS " -ex \"set non-stop $nonstop\""
clean_restart ${executable}
}
if ![runto_main] {
return -1
}
gdb_breakpoint [gdb_get_line_number "break-here"]
gdb_continue_to_breakpoint "break-here" ".* break-here .*"
# Also test with sched-lock to make sure we can follow the
# non-leader thread execing even though the main thread wasn't
# resumed before the exec.
if { $lock_sched } {
gdb_test_no_output "set scheduler-locking on"
}
if { $nonstop == "on" } {
gdb_test "thread 2" "Switching.*"
}
gdb_test "continue" \
".*is executing new program.*Breakpoint 1, main.* at .*" \
"continue over exec"
}
}
foreach nonstop {"on" "off"} {
foreach schedlock {"on" "off"} {
if {$schedlock == "on" && $nonstop == "on"} {
# Schedule locking has no effect in nonstop mode.
continue
}
do_test $schedlock $nonstop
}
}