Fix expected received signal message in testsuite
Commit Message
Quite a number of tests FAIL on Solaris due to a mismatch between
expected and received messages: the testsuite expects something like
Program received signal SIGABRT, Aborted.
while on Solaris it gets
Thread 2 received signal SIGABRT, Aborted.
For a simple testcase, info threads shows
(gdb) info threads
Id Target Id Frame
1 LWP 1 main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
* 2 Thread 1 (LWP 1) main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
I suspect this is due to support for the old pre-Solaris 9 MxN thread
model where user level threads were mapped to a different set of lwps.
For the moment, I'm dealing with this by allowing both forms of the
message in the testsuite. The patch is almost completely mechanical,
with the exception of gdb.base/sigbpt.exp where the introduction of a
new group in the RE required adjustments in the $expect_out indices.
Tested on sparcv9-sun-solaris2.11, x86_64-pc-solaris2.11, and
x86_64-pc-linux-gnu. Ok for master?
Rainer
Comments
Ping? It's been more than a week.
> Quite a number of tests FAIL on Solaris due to a mismatch between
> expected and received messages: the testsuite expects something like
>
> Program received signal SIGABRT, Aborted.
>
> while on Solaris it gets
>
> Thread 2 received signal SIGABRT, Aborted.
>
> For a simple testcase, info threads shows
>
> (gdb) info threads
> Id Target Id Frame
> 1 LWP 1 main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
> * 2 Thread 1 (LWP 1) main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>
> I suspect this is due to support for the old pre-Solaris 9 MxN thread
> model where user level threads were mapped to a different set of lwps.
>
> For the moment, I'm dealing with this by allowing both forms of the
> message in the testsuite. The patch is almost completely mechanical,
> with the exception of gdb.base/sigbpt.exp where the introduction of a
> new group in the RE required adjustments in the $expect_out indices.
>
> Tested on sparcv9-sun-solaris2.11, x86_64-pc-solaris2.11, and
> x86_64-pc-linux-gnu. Ok for master?
>
> Rainer
* Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> [2019-09-05 14:04:06 +0200]:
> Quite a number of tests FAIL on Solaris due to a mismatch between
> expected and received messages: the testsuite expects something like
>
> Program received signal SIGABRT, Aborted.
>
> while on Solaris it gets
>
> Thread 2 received signal SIGABRT, Aborted.
>
> For a simple testcase, info threads shows
>
> (gdb) info threads
> Id Target Id Frame
> 1 LWP 1 main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
> * 2 Thread 1 (LWP 1) main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>
> I suspect this is due to support for the old pre-Solaris 9 MxN thread
> model where user level threads were mapped to a different set of lwps.
>
> For the moment, I'm dealing with this by allowing both forms of the
> message in the testsuite. The patch is almost completely mechanical,
> with the exception of gdb.base/sigbpt.exp where the introduction of a
> new group in the RE required adjustments in the $expect_out indices.
I'm a little nervous about just allowing either "Thread" or "Program"
for all tests for all targets. Maybe others will disagree and think
I'm worrying about nothing, but I wonder if we could be more
conservative by adding a support function into lib/gdb.exp that takes
the name of a signal and returns the string we expect from GDB, which
we can then change based on Solaris/non-Solaris.
I haven't looked through the patch in enough detail to know if there's
any reason why this wouldn't work, so please push back if you think
the idea is unworkable.
Thanks,
Andrew
>
> Tested on sparcv9-sun-solaris2.11, x86_64-pc-solaris2.11, and
> x86_64-pc-linux-gnu. Ok for master?
>
> Rainer
>
> --
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2018-11-22 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
>
> * gdb.arch/aarch64-sighandler-regs.exp,
> gdb.arch/amd64-i386-address.exp, gdb.arch/i386-gnu-cfi.exp,
> gdb.arch/i386-mpx-call.exp, gdb.arch/i386-mpx-sigsegv.exp,
> gdb.arch/i386-mpx-simple_segv.exp, gdb.arch/i386-prologue.exp,
> gdb.arch/i386-size-overlap.exp, gdb.arch/i386-size.exp,
> gdb.arch/i386-sse-stack-align.exp, gdb.arch/i386-unwind.exp,
> gdb.arch/powerpc-stackless.exp, gdb.arch/s390-stackless.exp,
> gdb.arch/s390-tdbregs.exp, gdb.arch/s390-vregs.exp,
> gdb.arch/sparc64-adi.exp, gdb.base/auxv.exp,
> gdb.base/bp-cmds-continue-ctrl-c.exp, gdb.base/bp-permanent.exp,
> gdb.base/call-signal-resume.exp, gdb.base/ending-run.exp,
> gdb.base/exitsignal.exp, gdb.base/interrupt-noterm.exp,
> gdb.base/interrupt.exp, gdb.base/jit-reader.exp,
> gdb.base/kill-after-signal.exp, gdb.base/random-signal.exp,
> gdb.base/range-stepping.exp, gdb.base/relativedebug.exp,
> gdb.base/sigall.exp, gdb.base/sigbpt.exp,
> gdb.base/siginfo-addr.exp, gdb.base/siginfo-infcall.exp,
> gdb.base/siginfo-obj.exp, gdb.base/signest.exp,
> gdb.base/signull.exp, gdb.base/sigstep.exp, gdb.btrace/segv.exp,
> gdb.reverse/sigall-precsave.exp, gdb.reverse/sigall-reverse.exp,
> gdb.server/reconnect-ctrl-c.exp, gdb.server/solib-list.exp,
> gdb.trace/trace-condition.exp: Allow for Thread N received signal
> message.
> * gdb.base/sigbpt.exp: Adjust $expect_out indices.
>
> # HG changeset patch
> # Parent 83e8741eb69e875b4745b17494480e4271f0df40
> Fix expected received signal message in testsuite
>
> diff --git a/gdb/testsuite/gdb.arch/aarch64-sighandler-regs.exp b/gdb/testsuite/gdb.arch/aarch64-sighandler-regs.exp
> --- a/gdb/testsuite/gdb.arch/aarch64-sighandler-regs.exp
> +++ b/gdb/testsuite/gdb.arch/aarch64-sighandler-regs.exp
> @@ -88,7 +88,7 @@ proc check_regs {regtype regnums value p
> # Run until end of signal handler
>
> gdb_test "continue" \
> - "Continuing.*Program received signal SIGILL.*" \
> + "Continuing.*(Program|Thread .*) received signal SIGILL.*" \
> "continue until signal"
>
> gdb_breakpoint [gdb_get_line_number "exit(0)"]
> diff --git a/gdb/testsuite/gdb.arch/amd64-i386-address.exp b/gdb/testsuite/gdb.arch/amd64-i386-address.exp
> --- a/gdb/testsuite/gdb.arch/amd64-i386-address.exp
> +++ b/gdb/testsuite/gdb.arch/amd64-i386-address.exp
> @@ -32,7 +32,7 @@ gdb_run_cmd
>
> set test "trap stop"
> gdb_test_multiple "" $test {
> - -re "Program received signal SIGTRAP,.*_start .*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGTRAP,.*_start .*$gdb_prompt $" {
> pass $test
> }
> }
> diff --git a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
> --- a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
> +++ b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
> @@ -53,7 +53,7 @@ gdb_load ${binfile}
> gdb_run_cmd
>
> gdb_test_multiple {} "continue to abort()" {
> - -re ".*Program received signal SIGABRT,.*$gdb_prompt $" {
> + -re ".*(Program|Thread .*) received signal SIGABRT,.*$gdb_prompt $" {
> pass "continue to abort()"
> }
> }
> diff --git a/gdb/testsuite/gdb.arch/i386-mpx-call.exp b/gdb/testsuite/gdb.arch/i386-mpx-call.exp
> --- a/gdb/testsuite/gdb.arch/i386-mpx-call.exp
> +++ b/gdb/testsuite/gdb.arch/i386-mpx-call.exp
> @@ -57,7 +57,7 @@ set bndcfg_reg " = \\\{raw = $hex, confi
> preserved = $hex, enabled = $hex\\\}\\\}"
> set bndstatus_reg " = \\\{raw = $hex, status = \\\{bde = $hex,\
> error = $hex\\\}\\\}"
> -set u_fault [multi_line "Program received signal SIGSEGV, Segmentation fault" \
> +set u_fault [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
> "Upper bound violation while accessing address $hex" \
> "Bounds: \\\[lower = $hex, upper = $hex\\\]"]
>
> diff --git a/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.exp b/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.exp
> --- a/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.exp
> +++ b/gdb/testsuite/gdb.arch/i386-mpx-sigsegv.exp
> @@ -45,11 +45,11 @@ gdb_test_multiple "print have_mpx ()" "h
> }
> }
>
> -set u_fault [multi_line "Program received signal SIGSEGV, Segmentation fault" \
> +set u_fault [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
> "Upper bound violation while accessing address $hex" \
> "Bounds: \\\[lower = $hex, upper = $hex\\\]"]
>
> -set l_fault [multi_line "Program received signal SIGSEGV, Segmentation fault" \
> +set l_fault [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
> "Lower bound violation while accessing address $hex" \
> "Bounds: \\\[lower = $hex, upper = $hex\\\]"]
>
> diff --git a/gdb/testsuite/gdb.arch/i386-mpx-simple_segv.exp b/gdb/testsuite/gdb.arch/i386-mpx-simple_segv.exp
> --- a/gdb/testsuite/gdb.arch/i386-mpx-simple_segv.exp
> +++ b/gdb/testsuite/gdb.arch/i386-mpx-simple_segv.exp
> @@ -51,11 +51,11 @@ gdb_test_multiple "print have_mpx ()" "h
> }
> }
>
> -set violation [multi_line "Program received signal SIGSEGV, Segmentation fault" \
> +set violation [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
> "Upper bound violation while accessing address $hex" \
> "Bounds: \\\[lower = $hex, upper = $hex\\\]"]
>
> -set segv_with_exit "Program received signal SIGSEGV,\
> +set segv_with_exit "(Program|Thread .*) received signal SIGSEGV,\
> Segmentation fault.*$inferior_exited_re.*"
>
>
> diff --git a/gdb/testsuite/gdb.arch/i386-prologue.exp b/gdb/testsuite/gdb.arch/i386-prologue.exp
> --- a/gdb/testsuite/gdb.arch/i386-prologue.exp
> +++ b/gdb/testsuite/gdb.arch/i386-prologue.exp
> @@ -72,7 +72,7 @@ if ![runto_main] then {
>
> # Testcase for standard prologue.
>
> -gdb_test "continue" "Program received signal SIGTRAP.*" "continue to standard"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to standard"
>
> skip_breakpoint standard
>
> @@ -99,7 +99,7 @@ gdb_test "backtrace 10" \
> "first backtrace in stack_align_ecx"
>
> gdb_test "continue" \
> - "Program received signal SIGTRAP.*" \
> + "(Program|Thread .*) received signal SIGTRAP.*" \
> "continue in stack_align_ecx"
>
> skip_breakpoint stack_align_ecx
> @@ -127,7 +127,7 @@ gdb_test "backtrace 10" \
> "first backtrace in stack_align_edx"
>
> gdb_test "continue" \
> - "Program received signal SIGTRAP.*" \
> + "(Program|Thread .*) received signal SIGTRAP.*" \
> "continue in stack_align_edx"
>
> skip_breakpoint stack_align_edx
> @@ -155,7 +155,7 @@ gdb_test "backtrace 10" \
> "first backtrace in stack_align_eax"
>
> gdb_test "continue" \
> - "Program received signal SIGTRAP.*" \
> + "(Program|Thread .*) received signal SIGTRAP.*" \
> "continue in stack_align_eax"
>
> skip_breakpoint stack_align_eax
> @@ -171,7 +171,7 @@ gdb_test "info frame" \
>
> # Testcase from symtab/1253.
>
> -gdb_test "continue" "Program received signal SIGTRAP.*" "continue to gdb1253"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to gdb1253"
>
> skip_breakpoint gdb1253
>
> @@ -186,7 +186,7 @@ gdb_test "info frame" \
>
> # Testcase from backtrace/1718.
>
> -gdb_test "continue" "Program received signal SIGTRAP.*" "continue to gdb1718"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to gdb1718"
>
> skip_breakpoint gdb1718
>
> @@ -202,7 +202,7 @@ gdb_test "info frame" \
>
> # Testcase from backtrace/1338.
>
> -gdb_test "continue" "Program received signal SIGTRAP.*" "continue to gdb1338"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to gdb1338"
>
> skip_breakpoint gdb1338
>
> diff --git a/gdb/testsuite/gdb.arch/i386-size-overlap.exp b/gdb/testsuite/gdb.arch/i386-size-overlap.exp
> --- a/gdb/testsuite/gdb.arch/i386-size-overlap.exp
> +++ b/gdb/testsuite/gdb.arch/i386-size-overlap.exp
> @@ -41,7 +41,7 @@ gdb_load ${binfile}
> # We use gdb_run_cmd so this stands a chance to work for remote
> # targets too.
> gdb_run_cmd
> -gdb_test "" "Program received signal SIGTRAP.*" "run past main"
> +gdb_test "" "(Program|Thread .*) received signal SIGTRAP.*" "run past main"
>
> set message "backtrace shows the outer function"
> gdb_test_multiple "backtrace 10" $message {
> diff --git a/gdb/testsuite/gdb.arch/i386-size.exp b/gdb/testsuite/gdb.arch/i386-size.exp
> --- a/gdb/testsuite/gdb.arch/i386-size.exp
> +++ b/gdb/testsuite/gdb.arch/i386-size.exp
> @@ -46,7 +46,7 @@ gdb_load ${binfile}
> # We use gdb_run_cmd so this stands a chance to work for remote
> # targets too.
> gdb_run_cmd
> -gdb_test "" "Program received signal SIGTRAP.*" "run past main"
> +gdb_test "" "(Program|Thread .*) received signal SIGTRAP.*" "run past main"
>
> set message "backtrace shows no function"
> gdb_test_multiple "backtrace 10" $message {
> diff --git a/gdb/testsuite/gdb.arch/i386-sse-stack-align.exp b/gdb/testsuite/gdb.arch/i386-sse-stack-align.exp
> --- a/gdb/testsuite/gdb.arch/i386-sse-stack-align.exp
> +++ b/gdb/testsuite/gdb.arch/i386-sse-stack-align.exp
> @@ -48,7 +48,7 @@ foreach i {0 1 2 3 4} {
> -re " = 2\r\n$gdb_prompt $" {
> pass $test
> }
> - -re "Program received signal SIGSEGV, Segmentation fault\\..*\r\n$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV, Segmentation fault\\..*\r\n$gdb_prompt $" {
> fail $test
> }
> }
> diff --git a/gdb/testsuite/gdb.arch/i386-unwind.exp b/gdb/testsuite/gdb.arch/i386-unwind.exp
> --- a/gdb/testsuite/gdb.arch/i386-unwind.exp
> +++ b/gdb/testsuite/gdb.arch/i386-unwind.exp
> @@ -46,7 +46,7 @@ gdb_load ${binfile}
> # We use gdb_run_cmd so this stands a chance to work for remote
> # targets too.
> gdb_run_cmd
> -gdb_test "" "Program received signal SIGTRAP.*" "run past gdb1435"
> +gdb_test "" "(Program|Thread .*) received signal SIGTRAP.*" "run past gdb1435"
>
> gdb_test "backtrace 10" \
> "#1\[ \t]*$hex in gdb1435.*\r\n#2\[ \t\]*$hex in main.*" \
> diff --git a/gdb/testsuite/gdb.arch/powerpc-stackless.exp b/gdb/testsuite/gdb.arch/powerpc-stackless.exp
> --- a/gdb/testsuite/gdb.arch/powerpc-stackless.exp
> +++ b/gdb/testsuite/gdb.arch/powerpc-stackless.exp
> @@ -31,7 +31,7 @@ gdb_run_cmd
>
> set test "run until SIGSEGV"
> gdb_test_multiple "" $test {
> - -re "Program received signal SIGSEGV.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV.*$gdb_prompt $" {
> pass $test
> }
> }
> diff --git a/gdb/testsuite/gdb.arch/s390-stackless.exp b/gdb/testsuite/gdb.arch/s390-stackless.exp
> --- a/gdb/testsuite/gdb.arch/s390-stackless.exp
> +++ b/gdb/testsuite/gdb.arch/s390-stackless.exp
> @@ -29,7 +29,7 @@ gdb_run_cmd
>
> set test "run until SIGSEGV"
> gdb_test_multiple "" $test {
> - -re "Program received signal SIGSEGV.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV.*$gdb_prompt $" {
> pass $test
> }
> }
> diff --git a/gdb/testsuite/gdb.arch/s390-tdbregs.exp b/gdb/testsuite/gdb.arch/s390-tdbregs.exp
> --- a/gdb/testsuite/gdb.arch/s390-tdbregs.exp
> +++ b/gdb/testsuite/gdb.arch/s390-tdbregs.exp
> @@ -41,7 +41,7 @@ if ![runto_main] then {
> }
>
> gdb_test_multiple "next" "check for TE support" {
> - -re "Program received signal SIGILL,.*\r\n$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGILL,.*\r\n$gdb_prompt $" {
> unsupported "no TE support."
> return
> }
> @@ -59,7 +59,7 @@ set crashline [gdb_get_line_number "FAUL
> gdb_test "print \$tdb0" "\\\$\[0-9\]+ = <unavailable>" "tdb0 unavailable"
> gdb_test "print \$tr0" "\\\$\[0-9\]+ = <unavailable>" "tr0 unavailable"
> gdb_test "next" \
> - "Program received signal SIGSEGV, .*" \
> + "(Program|Thread .*) received signal SIGSEGV, .*" \
> "crash in transaction"
> gdb_test "print/x \$tdb0" "\\\$\[0-9\]+ = 0x1.*" "tdb0 available"
> gdb_test "set print symbol-filename" "" "set print symbol-filename"
> diff --git a/gdb/testsuite/gdb.arch/s390-vregs.exp b/gdb/testsuite/gdb.arch/s390-vregs.exp
> --- a/gdb/testsuite/gdb.arch/s390-vregs.exp
> +++ b/gdb/testsuite/gdb.arch/s390-vregs.exp
> @@ -52,7 +52,7 @@ gdb_test_multiple "x/i \$pc" "get PC at
> }
>
> gdb_test_multiple "stepi" "check for vector support" {
> - -re "Program received signal SIGILL,.*\r\n$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGILL,.*\r\n$gdb_prompt $" {
> unsupported "no vector support."
> return
> }
> diff --git a/gdb/testsuite/gdb.arch/sparc64-adi.exp b/gdb/testsuite/gdb.arch/sparc64-adi.exp
> --- a/gdb/testsuite/gdb.arch/sparc64-adi.exp
> +++ b/gdb/testsuite/gdb.arch/sparc64-adi.exp
> @@ -48,6 +48,6 @@ gdb_test "adi x/100 shmaddr" "${hex}00:\
> "examine new ADI"
> gdb_test_no_output "adi a/100 shmaddr=0x0" "reset ADI"
> gdb_test "continue" \
> - [multi_line "Program received signal SIGSEGV, Segmentation fault.*" \
> + [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault.*" \
> "ADI precise mismatch while accessing address $hex.*" ] \
> "continue to sigsegv"
> diff --git a/gdb/testsuite/gdb.base/auxv.exp b/gdb/testsuite/gdb.base/auxv.exp
> --- a/gdb/testsuite/gdb.base/auxv.exp
> +++ b/gdb/testsuite/gdb.base/auxv.exp
> @@ -126,7 +126,7 @@ set live_data [fetch_auxv "info auxv on
> set gcore_works [gdb_gcore_cmd "$gcorefile" "gcore"]
>
> # Let the program continue and die.
> -gdb_test continue ".*Program received signal.*"
> +gdb_test continue ".*(Program|Thread .*) received signal.*"
> gdb_test continue ".*Program terminated with signal.*"
>
> # Now collect the core dump it left.
> diff --git a/gdb/testsuite/gdb.base/bp-cmds-continue-ctrl-c.exp b/gdb/testsuite/gdb.base/bp-cmds-continue-ctrl-c.exp
> --- a/gdb/testsuite/gdb.base/bp-cmds-continue-ctrl-c.exp
> +++ b/gdb/testsuite/gdb.base/bp-cmds-continue-ctrl-c.exp
> @@ -84,7 +84,7 @@ proc do_test {} {
> fail "$test (SIGALRM)"
> return
> }
> - -re "Program received signal SIGINT.*\r\n$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGINT.*\r\n$gdb_prompt $" {
> send_log "$internal_pass (SIGINT)\n"
> }
> -re "Quit\r\n$gdb_prompt $" {
> diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp b/gdb/testsuite/gdb.base/bp-permanent.exp
> --- a/gdb/testsuite/gdb.base/bp-permanent.exp
> +++ b/gdb/testsuite/gdb.base/bp-permanent.exp
> @@ -134,7 +134,7 @@ proc test {always_inserted sw_watchpoint
> unsupported "failed to stop at permanent breakpoint"
> return
> }
> - -re "Program received signal SIGTRAP.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
> pass $test
> }
> }
> @@ -174,7 +174,7 @@ proc test {always_inserted sw_watchpoint
> # disabled, it should act as if we hadn't created it in the first
> # place. IOW, we should get a random signal, and, the breakpoint's
> # command should not run.
> - gdb_test "continue" "Program received signal SIGTRAP.*" \
> + gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" \
> "disabled permanent breakpoint doesn't explain stop"
>
> gdb_test "info breakpoints" \
> @@ -257,7 +257,7 @@ proc test {always_inserted sw_watchpoint
>
> set test "single-step to handler"
> gdb_test_multiple "stepi" $test {
> - -re "Program received signal SIGTRAP.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
> fail $test
> }
> -re "handler .*$gdb_prompt $" {
> diff --git a/gdb/testsuite/gdb.base/call-signal-resume.exp b/gdb/testsuite/gdb.base/call-signal-resume.exp
> --- a/gdb/testsuite/gdb.base/call-signal-resume.exp
> +++ b/gdb/testsuite/gdb.base/call-signal-resume.exp
> @@ -105,7 +105,7 @@ gdb_test "continue" "Breakpoint \[0-9\]*
>
> # Continue again, we should get a signal.
>
> -gdb_test "continue" "Program received signal .*" \
> +gdb_test "continue" "(Program|Thread .*) received signal .*" \
> "continue to receipt of signal"
>
> # Hand call another function that prematurely stops,
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -199,7 +199,7 @@ gdb_test_multiple "next" "step out of ma
> -re "_*start\[0-9\]* \\(\[^)\]*\\).*$gdb_prompt $" {
> pass "step out of main"
> }
> - -re ".*Program received signal SIGTRAP.*$gdb_prompt $" {
> + -re ".*(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
> pass "step out of main"
> }
> -re ".*in.*__uClibc_main.*$gdb_prompt $" {
> diff --git a/gdb/testsuite/gdb.base/exitsignal.exp b/gdb/testsuite/gdb.base/exitsignal.exp
> --- a/gdb/testsuite/gdb.base/exitsignal.exp
> +++ b/gdb/testsuite/gdb.base/exitsignal.exp
> @@ -47,7 +47,7 @@ gdb_test "print \$_exitcode" " = void" \
> "\$_exitcode is void before running"
>
> # Trigger SIGSEGV.
> -gdb_test "continue" "Program received signal SIGSEGV.*" "trigger SIGSEGV"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGSEGV.*" "trigger SIGSEGV"
>
> # Continue until the end.
> gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
> diff --git a/gdb/testsuite/gdb.base/interrupt-noterm.exp b/gdb/testsuite/gdb.base/interrupt-noterm.exp
> --- a/gdb/testsuite/gdb.base/interrupt-noterm.exp
> +++ b/gdb/testsuite/gdb.base/interrupt-noterm.exp
> @@ -67,7 +67,7 @@ gdb_test_multiple $test $test {
>
> set test "inferior received SIGINT"
> gdb_test_multiple "" $test {
> - -re "\r\nProgram received signal SIGINT.*" {
> + -re "\r\n(Program|Thread .*) received signal SIGINT.*" {
> # This appears after the prompt, which was already consumed
> # above.
> pass $test
> diff --git a/gdb/testsuite/gdb.base/interrupt.exp b/gdb/testsuite/gdb.base/interrupt.exp
> --- a/gdb/testsuite/gdb.base/interrupt.exp
> +++ b/gdb/testsuite/gdb.base/interrupt.exp
> @@ -82,7 +82,7 @@ if ![file exists $binfile] then {
> send_gdb "\003"
> set msg "send_gdb control C"
> gdb_test_multiple "" $msg {
> - -re "Program received signal SIGINT.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGINT.*$gdb_prompt $" {
> pass $msg
> }
> }
> @@ -93,7 +93,7 @@ if ![file exists $binfile] then {
> -re " = 4.*$gdb_prompt $" {
> pass $msg
> }
> - -re ".*Program received signal SIG(SEGV|ILL).*$gdb_prompt $" {
> + -re ".*(Program|Thread .*) received signal SIG(SEGV|ILL).*$gdb_prompt $" {
> setup_xfail "i*86-pc-linux*-gnu*"
> fail "child died when we called func1, skipped rest of tests"
> return
> @@ -166,7 +166,7 @@ if ![file exists $binfile] then {
> set msg "Send Control-C, second time"
> send_gdb "\003"
> gdb_test_multiple "" "$msg" {
> - -re "Program received signal SIGINT.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGINT.*$gdb_prompt $" {
> pass "$msg"
> }
> }
> diff --git a/gdb/testsuite/gdb.base/jit-reader.exp b/gdb/testsuite/gdb.base/jit-reader.exp
> --- a/gdb/testsuite/gdb.base/jit-reader.exp
> +++ b/gdb/testsuite/gdb.base/jit-reader.exp
> @@ -111,7 +111,7 @@ proc jit_reader_test {} {
>
> gdb_test_no_output "jit-reader-load ${jit_reader_bin}" "jit-reader-load"
> gdb_run_cmd
> - gdb_test "" "Program received signal SIGTRAP, .*" "expect SIGTRAP"
> + gdb_test "" "(Program|Thread .*) received signal SIGTRAP, .*" "expect SIGTRAP"
>
> # Test the JIT reader unwinder.
> with_test_prefix "with jit-reader" {
> diff --git a/gdb/testsuite/gdb.base/kill-after-signal.exp b/gdb/testsuite/gdb.base/kill-after-signal.exp
> --- a/gdb/testsuite/gdb.base/kill-after-signal.exp
> +++ b/gdb/testsuite/gdb.base/kill-after-signal.exp
> @@ -35,7 +35,7 @@ if ![runto_main] {
> return -1
> }
>
> -gdb_test "continue" "Program received signal SIGUSR1, .*"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGUSR1, .*"
> gdb_test "stepi" "\r\nhandler .*"
> gdb_test_multiple "kill" "kill" {
> -re "Kill the program being debugged\\? \\(y or n\\) $" {
> diff --git a/gdb/testsuite/gdb.base/random-signal.exp b/gdb/testsuite/gdb.base/random-signal.exp
> --- a/gdb/testsuite/gdb.base/random-signal.exp
> +++ b/gdb/testsuite/gdb.base/random-signal.exp
> @@ -47,7 +47,7 @@ proc do_test {} {
> # For this to work we must be sure to consume the "Continuing."
> # message first, or GDB's signal handler may not be in place.
> after 500 {send_gdb "\003"}
> - gdb_test "" "Program received signal SIGINT.*" "stop with control-c"
> + gdb_test "" "(Program|Thread .*) received signal SIGINT.*" "stop with control-c"
> }
>
> # With native debugging and "run" (with job control), the ctrl-c
> diff --git a/gdb/testsuite/gdb.base/range-stepping.exp b/gdb/testsuite/gdb.base/range-stepping.exp
> --- a/gdb/testsuite/gdb.base/range-stepping.exp
> +++ b/gdb/testsuite/gdb.base/range-stepping.exp
> @@ -193,7 +193,7 @@ if ![target_info exists gdb,nointerrupts
> incr vcont_r_counter
> exp_continue
> }
> - -re "Program received signal SIGINT.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGINT.*$gdb_prompt $" {
> pass $test
> }
> }
> diff --git a/gdb/testsuite/gdb.base/relativedebug.exp b/gdb/testsuite/gdb.base/relativedebug.exp
> --- a/gdb/testsuite/gdb.base/relativedebug.exp
> +++ b/gdb/testsuite/gdb.base/relativedebug.exp
> @@ -43,7 +43,7 @@ gdb_test_multiple $test $test {
> }
>
> # pause () -> SIGALRM -> handler () -> abort ()
> -gdb_test "continue" "Program received signal SIGABRT.*"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGABRT.*"
>
> # Backtracing through pause broke if glibc has been prelinked,
> # because the separate debug files in /usr/lib/debug had different
> diff --git a/gdb/testsuite/gdb.base/sigall.exp b/gdb/testsuite/gdb.base/sigall.exp
> --- a/gdb/testsuite/gdb.base/sigall.exp
> +++ b/gdb/testsuite/gdb.base/sigall.exp
> @@ -50,7 +50,7 @@ proc test_one_sig {nextsig} {
> }
>
> gdb_test "continue" \
> - "Continuing.*Program received signal SIG$esig.*" \
> + "Continuing.*(Program|Thread .*) received signal SIG$esig.*" \
> "get signal $esig"
> }
>
> @@ -180,7 +180,7 @@ gdb_test "handle SIGTERM stop print" \
> "SIGTERM\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes.*"
> gdb_test "b handle_TERM" "Breakpoint \[0-9\]+ .*"
> gdb_test "continue" \
> - "Continuing.*Program received signal SIGTERM.*" \
> + "Continuing.*(Program|Thread .*) received signal SIGTERM.*" \
> "get signal TERM"
> gdb_test "continue" "Breakpoint.*handle_TERM.*" "send signal TERM"
> gdb_continue_to_end "continue to sigall exit"
> diff --git a/gdb/testsuite/gdb.base/sigbpt.exp b/gdb/testsuite/gdb.base/sigbpt.exp
> --- a/gdb/testsuite/gdb.base/sigbpt.exp
> +++ b/gdb/testsuite/gdb.base/sigbpt.exp
> @@ -76,9 +76,9 @@ gdb_test "advance bowler" "bowler.*" "ad
> set test "stepping to fault"
> set signame "SIGSEGV"
> gdb_test_multiple "stepi" "$test" {
> - -re "Program received signal (SIGBUS|SIGSEGV).*pc(\r\n| *) *=> (0x\[0-9a-f\]*).*$gdb_prompt $" {
> - set signame $expect_out(1,string)
> - set segv_addr $expect_out(3,string)
> + -re "(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*pc(\r\n| *) *=> (0x\[0-9a-f\]*).*$gdb_prompt $" {
> + set signame $expect_out(2,string)
> + set segv_addr $expect_out(4,string)
> pass "$test"
> }
> -re " .*pc(\r\n| *)=> (0x\[0-9a-f\]*).*bowler.*$gdb_prompt $" {
> @@ -171,7 +171,7 @@ proc stepi_out { name args } {
> send_gdb "stepi\n"
> exp_continue
> }
> - -re "Program received signal SIGSEGV.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV.*$gdb_prompt $" {
> kfail gdb/8807 "$test (executed fault insn)"
> }
> -re "Breakpoint.*pc(\r\n| *)[at_segv] .*bowler.*$gdb_prompt $" {
> @@ -236,7 +236,7 @@ proc cont_out { name args } {
>
> # Now single step the faulted instrction at that breakpoint.
> gdb_test "stepi" \
> - "Program received signal ${signame}.*pc(\r\n| *)=> [at_segv] .*" \
> + "(Program|Thread .*) received signal ${signame}.*pc(\r\n| *)=> [at_segv] .*" \
> "${name}; stepi fault"
>
> # Clear any breakpoints
> diff --git a/gdb/testsuite/gdb.base/siginfo-addr.exp b/gdb/testsuite/gdb.base/siginfo-addr.exp
> --- a/gdb/testsuite/gdb.base/siginfo-addr.exp
> +++ b/gdb/testsuite/gdb.base/siginfo-addr.exp
> @@ -40,7 +40,7 @@ if ![runto_main] then {
> }
>
> # Run to the signal.
> -gdb_test "continue" ".*Program received signal SIGSEGV.*" "continue to signal"
> +gdb_test "continue" ".*(Program|Thread .*) received signal SIGSEGV.*" "continue to signal"
>
> gdb_breakpoint "pass"
>
> diff --git a/gdb/testsuite/gdb.base/siginfo-infcall.exp b/gdb/testsuite/gdb.base/siginfo-infcall.exp
> --- a/gdb/testsuite/gdb.base/siginfo-infcall.exp
> +++ b/gdb/testsuite/gdb.base/siginfo-infcall.exp
> @@ -31,7 +31,7 @@ if ![runto_main] {
> gdb_breakpoint "pass"
> gdb_breakpoint "fail"
>
> -gdb_test "continue" "Program received signal SIGUSR1, .*" "continue to SIGUSR1"
> +gdb_test "continue" "(Program|Thread .*) received signal SIGUSR1, .*" "continue to SIGUSR1"
>
> gdb_test "p callme ()" " = 42"
>
> diff --git a/gdb/testsuite/gdb.base/siginfo-obj.exp b/gdb/testsuite/gdb.base/siginfo-obj.exp
> --- a/gdb/testsuite/gdb.base/siginfo-obj.exp
> +++ b/gdb/testsuite/gdb.base/siginfo-obj.exp
> @@ -45,7 +45,7 @@ if ![runto_main] then {
> }
>
> # Run to the signal.
> -gdb_test "continue" ".*Program received signal SIGSEGV.*" "continue to signal"
> +gdb_test "continue" ".*(Program|Thread .*) received signal SIGSEGV.*" "continue to signal"
>
> # Try to generate a core file, for a later test.
> set gcorefile [standard_output_file $testfile.gcore]
> @@ -104,7 +104,7 @@ if ![runto_main] then {
> }
>
> # Run to the signal.
> -gdb_test "continue" ".*Program received signal SIGSEGV.*" "continue to signal"
> +gdb_test "continue" ".*(Program|Thread .*) received signal SIGSEGV.*" "continue to signal"
>
> set test "set si_addr"
> gdb_test "p \$_siginfo._sifields._sigfault.si_addr = 0x666" " = \\(void \\*\\) 0x666"
> diff --git a/gdb/testsuite/gdb.base/signest.exp b/gdb/testsuite/gdb.base/signest.exp
> --- a/gdb/testsuite/gdb.base/signest.exp
> +++ b/gdb/testsuite/gdb.base/signest.exp
> @@ -44,7 +44,7 @@ if { [is_address_zero_readable] } {
>
> # Run until we hit the SIGSEGV (or SIGBUS on some platforms).
> gdb_test "continue" \
> - ".*Program received signal (SIGBUS|SIGSEGV).*bowler.*" \
> + ".*(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*bowler.*" \
> "continue to fault"
>
> # Insert conditional breakpoint at faulting instruction
> @@ -56,6 +56,6 @@ gdb_test "handle SIGBUS nostop print pas
>
> # Step off the faulting instruction into the handler, triggering nested faults
> gdb_test "continue" \
> - ".*Program received signal (SIGBUS|SIGSEGV).*Program received signal (SIGBUS|SIGSEGV).*exited normally.*" \
> + ".*(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*exited normally.*" \
> "run through nested faults"
>
> diff --git a/gdb/testsuite/gdb.base/signull.exp b/gdb/testsuite/gdb.base/signull.exp
> --- a/gdb/testsuite/gdb.base/signull.exp
> +++ b/gdb/testsuite/gdb.base/signull.exp
> @@ -72,14 +72,14 @@ set test "probe function pointer"
> set function_pointer code_entry_point
> set signame "SIGSEGV"
> gdb_test_multiple "continue" "$test" {
> - -re "Program received signal SIGSEGV.*bowler .*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV.*bowler .*$gdb_prompt $" {
> set function_pointer code_descriptor
> pass "$test (function descriptor)"
> }
> - -re "Program received signal SIGSEGV.*0.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV.*0.*$gdb_prompt $" {
> pass "$test (function entry-point)"
> }
> - -re "Program received signal SIGBUS.*0.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGBUS.*0.*$gdb_prompt $" {
> set signame SIGBUS
> pass "$test (function entry-point)"
> }
> @@ -103,7 +103,7 @@ proc test_segv { name tag bt_from_segv b
> gdb_test continue "Breakpoint.* bowler.*" "${name}; start with the bowler"
> # NB: Don't use $tag in the testname - changes across systems.
> gdb_test_no_output "set test = $tag" "${name}; select the pointer type"
> - gdb_test continue "Program received signal ${signame}.*" \
> + gdb_test continue "(Program|Thread .*) received signal ${signame}.*" \
> "${name}; take the ${signame}"
> gdb_test backtrace $bt_from_segv "${name}; backtrace from ${signame}"
> gdb_test continue "Breakpoint.* keeper.*" "${name}; continue to the keeper"
> diff --git a/gdb/testsuite/gdb.base/sigstep.exp b/gdb/testsuite/gdb.base/sigstep.exp
> --- a/gdb/testsuite/gdb.base/sigstep.exp
> +++ b/gdb/testsuite/gdb.base/sigstep.exp
> @@ -91,7 +91,7 @@ proc advance { enter_cmd in_handler_pref
> } else {
> gdb_test "handle SIGALRM print pass stop"
> gdb_test "handle SIGVTALRM print pass stop"
> - gdb_test "continue" "Program received signal.*" "continue to signal"
> + gdb_test "continue" "(Program|Thread .*) received signal.*" "continue to signal"
> }
> gdb_test "$enter_cmd" ".*handler .*" "$enter_cmd to handler"
>
> @@ -150,7 +150,7 @@ set in_handler_map {
>
> set test "advance in handler"
> gdb_test_multiple "advance $other_handler_location" $test {
> - -re "Program received signal SIGTRAP.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
> # On some versions of Linux (observed on
> # 3.16.4-200.fc20.x86_64), using PTRACE_SINGLESTEP+sig
> # to step into a signal handler, and then issuing
> diff --git a/gdb/testsuite/gdb.btrace/segv.exp b/gdb/testsuite/gdb.btrace/segv.exp
> --- a/gdb/testsuite/gdb.btrace/segv.exp
> +++ b/gdb/testsuite/gdb.btrace/segv.exp
> @@ -34,7 +34,7 @@ if ![runto_main] {
> # trace the test code
> gdb_test_no_output "record btrace"
> gdb_test "continue" [multi_line \
> - "Program received signal SIGSEGV, Segmentation fault\." \
> + "(Program|Thread .*) received signal SIGSEGV, Segmentation fault\." \
> "0x0* in \\\?\\\? \\\(\\\)" \
> ] "cont to segv"
>
> diff --git a/gdb/testsuite/gdb.reverse/sigall-precsave.exp b/gdb/testsuite/gdb.reverse/sigall-precsave.exp
> --- a/gdb/testsuite/gdb.reverse/sigall-precsave.exp
> +++ b/gdb/testsuite/gdb.reverse/sigall-precsave.exp
> @@ -53,10 +53,10 @@ proc test_one_sig {nextsig} {
> }
> set testmsg "get signal $thissig"
> gdb_test_multiple "continue" $testmsg {
> - -re "Program received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
> fail "$testmsg (wrong location)"
> }
> - -re "Program received signal SIG$thissig.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIG$thissig.*$gdb_prompt $" {
> pass $testmsg
> }
> -re "Breakpoint.* handle_$thissig.*$gdb_prompt $" {
> @@ -114,7 +114,7 @@ proc test_one_sig_reverse {prevsig} {
> -re "Breakpoint.*handle_.*$gdb_prompt " {
> pass "$testmsg (un-handled)"
> }
> - -re "Program received signal SIG$prevsig.*$gdb_prompt " {
> + -re "(Program|Thread .*) received signal SIG$prevsig.*$gdb_prompt " {
> pass "reverse to signal event, $prevsig"
>
> set nested_testmsg "reverse signal delivered"
> @@ -299,7 +299,7 @@ gdb_test "handle SIGTERM stop print" \
> "SIGTERM\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes.*"
> gdb_test "b handle_TERM" "Breakpoint \[0-9\]+ .*"
> gdb_test "continue" \
> - "Continuing.*Program received signal SIGTERM.*" \
> + "Continuing.*(Program|Thread .*) received signal SIGTERM.*" \
> "get signal TERM"
> gdb_test "continue" "Breakpoint.*handle_TERM.*" "send signal TERM"
>
> diff --git a/gdb/testsuite/gdb.reverse/sigall-reverse.exp b/gdb/testsuite/gdb.reverse/sigall-reverse.exp
> --- a/gdb/testsuite/gdb.reverse/sigall-reverse.exp
> +++ b/gdb/testsuite/gdb.reverse/sigall-reverse.exp
> @@ -52,10 +52,10 @@ proc test_one_sig {nextsig} {
> }
> set testmsg "get signal $thissig"
> gdb_test_multiple "continue" $testmsg {
> - -re "Program received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
> fail "$testmsg (wrong location)"
> }
> - -re "Program received signal SIG$thissig.*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIG$thissig.*$gdb_prompt $" {
> pass $testmsg
> }
> -re "Breakpoint.* handle_$thissig.*$gdb_prompt $" {
> @@ -113,7 +113,7 @@ proc test_one_sig_reverse {prevsig} {
> -re "Breakpoint.*handle_.*$gdb_prompt " {
> pass "$testmsg (un-handled)"
> }
> - -re "Program received signal SIG$prevsig.*$gdb_prompt " {
> + -re "(Program|Thread .*) received signal SIG$prevsig.*$gdb_prompt " {
> pass "reverse to signal event, $prevsig"
>
> set nested_testmsg "reverse signal delivered"
> @@ -247,7 +247,7 @@ gdb_test "handle SIGTERM stop print" \
> "SIGTERM\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes.*"
> gdb_test "b handle_TERM" "Breakpoint \[0-9\]+ .*"
> gdb_test "continue" \
> - "Continuing.*Program received signal SIGTERM.*" \
> + "Continuing.*(Program|Thread .*) received signal SIGTERM.*" \
> "get signal TERM"
> gdb_test "continue" "Breakpoint.*handle_TERM.*" "send signal TERM"
>
> diff --git a/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp b/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp
> --- a/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp
> +++ b/gdb/testsuite/gdb.server/reconnect-ctrl-c.exp
> @@ -58,7 +58,7 @@ proc connect_continue_ctrl_c {} {
> }
>
> after 1000 {send_gdb "\003"}
> - gdb_test "" "Program received signal SIGINT.*" "stop with control-c"
> + gdb_test "" "(Program|Thread .*) received signal SIGINT.*" "stop with control-c"
> }
>
> with_test_prefix "first" {
> diff --git a/gdb/testsuite/gdb.server/solib-list.exp b/gdb/testsuite/gdb.server/solib-list.exp
> --- a/gdb/testsuite/gdb.server/solib-list.exp
> +++ b/gdb/testsuite/gdb.server/solib-list.exp
> @@ -99,7 +99,7 @@ foreach nonstop { 0 1 } { with_test_pref
> }
> }
>
> - gdb_test "continue" "Program received signal SIGUSR1, .*"
> + gdb_test "continue" "(Program|Thread .*) received signal SIGUSR1, .*"
> gdb_test "sharedlibrary" ".*"
> gdb_test "p libvar" " = 23"
> }}
> diff --git a/gdb/testsuite/gdb.trace/trace-condition.exp b/gdb/testsuite/gdb.trace/trace-condition.exp
> --- a/gdb/testsuite/gdb.trace/trace-condition.exp
> +++ b/gdb/testsuite/gdb.trace/trace-condition.exp
> @@ -99,7 +99,7 @@ proc test_tracepoints { trace_command co
> -re ".*Breakpoint \[0-9\]+, end .*$gdb_prompt $" {
> pass "advance through tracing"
> }
> - -re "Program received signal SIGSEGV, Segmentation fault\\..*$gdb_prompt $" {
> + -re "(Program|Thread .*) received signal SIGSEGV, Segmentation fault\\..*$gdb_prompt $" {
> if { $kfail_proc != 0 } {
> $kfail_proc $trace_command
> }
Hi Andrew,
> * Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> [2019-09-05 14:04:06 +0200]:
>
>> Quite a number of tests FAIL on Solaris due to a mismatch between
>> expected and received messages: the testsuite expects something like
>>
>> Program received signal SIGABRT, Aborted.
>>
>> while on Solaris it gets
>>
>> Thread 2 received signal SIGABRT, Aborted.
>>
>> For a simple testcase, info threads shows
>>
>> (gdb) info threads
>> Id Target Id Frame
>> 1 LWP 1 main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>> * 2 Thread 1 (LWP 1) main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>>
>> I suspect this is due to support for the old pre-Solaris 9 MxN thread
>> model where user level threads were mapped to a different set of lwps.
>>
>> For the moment, I'm dealing with this by allowing both forms of the
>> message in the testsuite. The patch is almost completely mechanical,
>> with the exception of gdb.base/sigbpt.exp where the introduction of a
>> new group in the RE required adjustments in the $expect_out indices.
>
> I'm a little nervous about just allowing either "Thread" or "Program"
> for all tests for all targets. Maybe others will disagree and think
> I'm worrying about nothing, but I wonder if we could be more
> conservative by adding a support function into lib/gdb.exp that takes
> the name of a signal and returns the string we expect from GDB, which
> we can then change based on Solaris/non-Solaris.
>
> I haven't looked through the patch in enough detail to know if there's
> any reason why this wouldn't work, so please push back if you think
> the idea is unworkable.
sorry for letting the ball drop on this one. Only recently did I
stumble across it again when looking into a related issue and now I
finally understand why Solaris is different here.
[Thread starting at https://sourceware.org/ml/gdb-patches/2019-09/msg00050.html]
* Consider the following testcase:
$ cat selfkill.c
#include <sys/types.h>
#include <signal.h>
#include <unistd.h>
#include <pthread.h>
void *
selfkill (void *arg)
{
kill (getpid (), SIGINT);
return NULL;
}
int
main (void)
{
#ifdef _REENTRANT
pthread_t tid;
pthread_create (&tid, NULL, selfkill, NULL);
pthread_join (tid, NULL);
#else
selfkill (NULL);
#endif
return 0;
}
* Now compile on Solaris 9, both without and with -pthread:
$ gcc -o selfkill selfkill.c
$ gcc -pthread -o selfkill-mt selfkill.c
* Run the identical binaries and versions of gdb (7.11 here) on both
Solaris 9 and Solaris 10:
$ gdb -q --batch -ex run selfkill{,-mt}
** Solaris 9, selfkill:
Program received signal SIGINT, Interrupt.
0xb5d54186 in _libc_kill () from /usr/lib/libc.so.1
** Solaris 9, selfkill-mt:
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP 2 ]
[New Thread 2 (LWP 2)]
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 1 (LWP 1)]
0xb5c9fad5 in _lwp_wait () from /usr/lib/libc.so.1
** Solaris 10, selfkill:
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 1 (LWP 1)]
0xfef0c165 in kill () from /lib/libc.so.1
** Solaris 10, selfkill-mt:
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP 2 ]
[New Thread 2 (LWP 2)]
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 1 (LWP 1)]
0xfeedca05 in __lwp_wait () from /lib/libc.so.1
** Trying the same on Linux/x86_64, one sees the same behaviour as on
Solaris 9: non-threaded and threaded programs behave differently.
* As you can see, on Solaris 10 even the not explicitly threaded version
of the test is shown as threaded, explaining the difference in the
"... received signal" messages.
This is a consequence of the Thread Model Unification Project in
Solaris 10, which removed the difference between non-threaded and
threaded processes. This has nothing to do with the removal of the
pre-Solaris 9 MxN multilevel thread model as I'd originally
suspected.
That said, I've reworked the patch to use a support function in gdb.exp
(signal_recv_msg) to hide the difference between the Solaris and
non-Solaris cases. One could think about introducing an additional arg
(threaded) so both the explicitly threaded and other cases could be
handled similarly.
So far lightly tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.
Rainer
Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
> Hi Andrew,
>
>> * Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> [2019-09-05 14:04:06 +0200]:
>>
>>> Quite a number of tests FAIL on Solaris due to a mismatch between
>>> expected and received messages: the testsuite expects something like
>>>
>>> Program received signal SIGABRT, Aborted.
>>>
>>> while on Solaris it gets
>>>
>>> Thread 2 received signal SIGABRT, Aborted.
>>>
>>> For a simple testcase, info threads shows
>>>
>>> (gdb) info threads
>>> Id Target Id Frame
>>> 1 LWP 1 main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>>> * 2 Thread 1 (LWP 1) main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>>>
>>> I suspect this is due to support for the old pre-Solaris 9 MxN thread
>>> model where user level threads were mapped to a different set of lwps.
>>>
>>> For the moment, I'm dealing with this by allowing both forms of the
>>> message in the testsuite. The patch is almost completely mechanical,
>>> with the exception of gdb.base/sigbpt.exp where the introduction of a
>>> new group in the RE required adjustments in the $expect_out indices.
>>
>> I'm a little nervous about just allowing either "Thread" or "Program"
>> for all tests for all targets. Maybe others will disagree and think
>> I'm worrying about nothing, but I wonder if we could be more
>> conservative by adding a support function into lib/gdb.exp that takes
>> the name of a signal and returns the string we expect from GDB, which
>> we can then change based on Solaris/non-Solaris.
>>
>> I haven't looked through the patch in enough detail to know if there's
>> any reason why this wouldn't work, so please push back if you think
>> the idea is unworkable.
>
> sorry for letting the ball drop on this one. Only recently did I
> stumble across it again when looking into a related issue and now I
> finally understand why Solaris is different here.
>
> [Thread starting at https://sourceware.org/ml/gdb-patches/2019-09/msg00050.html]
>
> * Consider the following testcase:
>
> $ cat selfkill.c
> #include <sys/types.h>
> #include <signal.h>
> #include <unistd.h>
> #include <pthread.h>
>
> void *
> selfkill (void *arg)
> {
> kill (getpid (), SIGINT);
> return NULL;
> }
>
> int
> main (void)
> {
> #ifdef _REENTRANT
> pthread_t tid;
> pthread_create (&tid, NULL, selfkill, NULL);
> pthread_join (tid, NULL);
> #else
> selfkill (NULL);
> #endif
> return 0;
> }
>
> * Now compile on Solaris 9, both without and with -pthread:
>
> $ gcc -o selfkill selfkill.c
> $ gcc -pthread -o selfkill-mt selfkill.c
>
> * Run the identical binaries and versions of gdb (7.11 here) on both
> Solaris 9 and Solaris 10:
>
> $ gdb -q --batch -ex run selfkill{,-mt}
>
> ** Solaris 9, selfkill:
>
> Program received signal SIGINT, Interrupt.
> 0xb5d54186 in _libc_kill () from /usr/lib/libc.so.1
>
> ** Solaris 9, selfkill-mt:
>
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
> [New LWP 2 ]
> [New Thread 2 (LWP 2)]
>
> Thread 2 received signal SIGINT, Interrupt.
> [Switching to Thread 1 (LWP 1)]
> 0xb5c9fad5 in _lwp_wait () from /usr/lib/libc.so.1
>
> ** Solaris 10, selfkill:
>
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
>
> Thread 2 received signal SIGINT, Interrupt.
> [Switching to Thread 1 (LWP 1)]
> 0xfef0c165 in kill () from /lib/libc.so.1
>
> ** Solaris 10, selfkill-mt:
>
> [Thread debugging using libthread_db enabled]
> [New Thread 1 (LWP 1)]
> [New LWP 2 ]
> [New Thread 2 (LWP 2)]
>
> Thread 2 received signal SIGINT, Interrupt.
> [Switching to Thread 1 (LWP 1)]
> 0xfeedca05 in __lwp_wait () from /lib/libc.so.1
>
> ** Trying the same on Linux/x86_64, one sees the same behaviour as on
> Solaris 9: non-threaded and threaded programs behave differently.
>
> * As you can see, on Solaris 10 even the not explicitly threaded version
> of the test is shown as threaded, explaining the difference in the
> "... received signal" messages.
>
> This is a consequence of the Thread Model Unification Project in
> Solaris 10, which removed the difference between non-threaded and
> threaded processes. This has nothing to do with the removal of the
> pre-Solaris 9 MxN multilevel thread model as I'd originally
> suspected.
I tried to take a look at this a little. The only Solaris machines I
have access to run on Sparc, not x86-64, but hopefully should still have
much the same behaviour.
I did manage to (eventually) build GDB on one of these machines, but,
I'm not sure if I built it wrong, or if the Sparc/Solaris support is
just bad, but GDB was crashing all over the place with assertion
failures.
Still, with some persistence I could see the behaviour you observe.
Now, I've not done any Solaris work in >10years, so I don't claim to be
any kind of expert, but I wonder if the fix you're proposing here isn't
simply hiding a GDB bug.
I wrote a simple test program that starts 3 worker threads and then
blocks. Here's the 'info threads' output for GNU/Linux:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7da3740 (LWP 2243115) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
2 Thread 0x7ffff7da2700 (LWP 2243118) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
3 Thread 0x7ffff75a1700 (LWP 2243119) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
4 Thread 0x7ffff6da0700 (LWP 2243120) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
What you'd expect. Now here's the same on Solaris:
(gdb) info threads
Id Target Id Frame
* 1 LWP 1 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
2 LWP 4 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
3 LWP 3 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
4 LWP 2 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
5 Thread 1 (LWP 1) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
6 Thread 2 (LWP 2) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
7 Thread 3 (LWP 3) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
8 Thread 4 (LWP 4) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
This is inline with what you describe, but, I think we can all agree,
this seems a little odd; are there really 8 thread like things running
as part of this process? The output of `ps -aL` would suggest not:
$ ps -aL
PID LWP TTY LTIME CMD
3855 1 pts/6 0:00 thr.x
3855 2 pts/6 0:00 thr.x
3855 3 pts/6 0:00 thr.x
3855 4 pts/6 0:00 thr.x
4132 1 pts/8 0:00 ps
And also, when I run the same test application using the dbx debugger, I
see this:
(dbx) threads
*> t@1 a l@1 ?() signal SIGINT in ___nanosleep()
t@2 a l@2 thread_worker() running in ___nanosleep()
t@3 a l@3 thread_worker() running in ___nanosleep()
t@4 a l@4 thread_worker() running in ___nanosleep()
So here, the process is represented as just 4 thread like things.
So, why does GDB think there are 8, while every tools that ships with
Solaris seems to think there are 4? My guess, is that is has something
to do with the thread lookup code in sol-thread.c, and/or the operation
of libthread-db.
So, what I run your original selfkill test application, and use GDB to
break on GDB's add_thread_with_info function (the thing that is
responsible for printing the "New Thread ..." message), here's what I
see:
(gdb) bt
#0 add_thread_with_info (targ=targ@entry=0x940678 <the_procfs_target>, ptid=..., priv=priv@entry=0x0) at ../../src/gdb/thread.c:290
#1 0x0053b61c in add_thread (targ=0x940678 <the_procfs_target>, ptid=...) at ../../src/gdb/thread.c:305
#2 0x004ab5f4 in sol_thread_target::wait (this=<optimized out>, ptid=..., ourstatus=0xffbff620, options=...) at ../../src/gdb/sol-thread.c:459
#3 0x0053019c in target_wait (ptid=..., status=status@entry=0xffbff620, options=...) at ../../src/gdb/target.c:2598
#4 0x00395478 in do_target_wait_1 (inf=inf@entry=0x969288, ptid=..., status=status@entry=0xffbff620, options=<error reading variable: Cannot access memory at address 0x0>) at ../../src/gdb/infrun.c:3763
#5 0x003a7e8c in <lambda(inferior*)>::operator() (inf=0x969288, __closure=<synthetic pointer>) at ../../src/gdb/infrun.c:3822
#6 do_target_wait (options=..., ecs=0xffbff600) at ../../src/gdb/infrun.c:3841
#7 fetch_inferior_event () at ../../src/gdb/infrun.c:4201
#8 0x001b0bd8 in check_async_event_handlers () at ../../src/gdb/async-event.c:337
#9 0x006c4e3c in gdb_do_one_event (mstimeout=mstimeout@entry=-1) at ../../src/gdbsupport/event-loop.cc:221
#10 0x003d7ea0 in start_event_loop () at ../../src/gdb/main.c:411
#11 captured_command_loop () at ../../src/gdb/main.c:471
#12 0x003d9fa8 in captured_main (data=0xffbff84c) at ../../src/gdb/main.c:1330
#13 gdb_main (args=args@entry=0xffbff84c) at ../../src/gdb/main.c:1345
#14 0x006f7c5c in main (argc=4, argv=0xffbff8bc) at ../../src/gdb/gdb.c:32
(gdb) frame 2
#2 0x004ab5f4 in sol_thread_target::wait (this=<optimized out>, ptid=..., ourstatus=0xffbff620, options=...) at ../../src/gdb/sol-thread.c:459
459 add_thread (proc_target, rtnval);
(gdb) p rtnval
$1 = {m_pid = 7218, m_lwp = 0, m_tid = 1}
(gdb) p current_inferior_.m_obj->thread_list.m_front.ptid
$2 = {m_pid = 7218, m_lwp = 1, m_tid = 0}
(gdb)
What this is telling us, is that, when GDB stopped after the ::wait
call, the ptid_t it got back was '{m_pid = 7218, m_lwp = 0, m_tid = 1}',
however, the original thread that GDB found when starting the
application was '{m_pid = 7218, m_lwp = 1, m_tid = 0}'.
This difference is what causes GDB to add the new thread.
My guess is that this m_lwp/m_tid difference is a bug somewhere in the
stack, and that really, we should be seeing the same ptid_t here. If we
did, then GDB would not add the new thread, and the test messages would
not change.
What are your thoughts on this analysis?
Thanks,
Andrew
Andrew Burgess <aburgess@redhat.com> writes:
> Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:
>
>> Hi Andrew,
>>
>>> * Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> [2019-09-05 14:04:06 +0200]:
>>>
>>>> Quite a number of tests FAIL on Solaris due to a mismatch between
>>>> expected and received messages: the testsuite expects something like
>>>>
>>>> Program received signal SIGABRT, Aborted.
>>>>
>>>> while on Solaris it gets
>>>>
>>>> Thread 2 received signal SIGABRT, Aborted.
>>>>
>>>> For a simple testcase, info threads shows
>>>>
>>>> (gdb) info threads
>>>> Id Target Id Frame
>>>> 1 LWP 1 main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>>>> * 2 Thread 1 (LWP 1) main () at /vol/src/gnu/gdb/doc/bugs/ua.c:5
>>>>
>>>> I suspect this is due to support for the old pre-Solaris 9 MxN thread
>>>> model where user level threads were mapped to a different set of lwps.
>>>>
>>>> For the moment, I'm dealing with this by allowing both forms of the
>>>> message in the testsuite. The patch is almost completely mechanical,
>>>> with the exception of gdb.base/sigbpt.exp where the introduction of a
>>>> new group in the RE required adjustments in the $expect_out indices.
>>>
>>> I'm a little nervous about just allowing either "Thread" or "Program"
>>> for all tests for all targets. Maybe others will disagree and think
>>> I'm worrying about nothing, but I wonder if we could be more
>>> conservative by adding a support function into lib/gdb.exp that takes
>>> the name of a signal and returns the string we expect from GDB, which
>>> we can then change based on Solaris/non-Solaris.
>>>
>>> I haven't looked through the patch in enough detail to know if there's
>>> any reason why this wouldn't work, so please push back if you think
>>> the idea is unworkable.
>>
>> sorry for letting the ball drop on this one. Only recently did I
>> stumble across it again when looking into a related issue and now I
>> finally understand why Solaris is different here.
>>
>> [Thread starting at https://sourceware.org/ml/gdb-patches/2019-09/msg00050.html]
>>
>> * Consider the following testcase:
>>
>> $ cat selfkill.c
>> #include <sys/types.h>
>> #include <signal.h>
>> #include <unistd.h>
>> #include <pthread.h>
>>
>> void *
>> selfkill (void *arg)
>> {
>> kill (getpid (), SIGINT);
>> return NULL;
>> }
>>
>> int
>> main (void)
>> {
>> #ifdef _REENTRANT
>> pthread_t tid;
>> pthread_create (&tid, NULL, selfkill, NULL);
>> pthread_join (tid, NULL);
>> #else
>> selfkill (NULL);
>> #endif
>> return 0;
>> }
>>
>> * Now compile on Solaris 9, both without and with -pthread:
>>
>> $ gcc -o selfkill selfkill.c
>> $ gcc -pthread -o selfkill-mt selfkill.c
>>
>> * Run the identical binaries and versions of gdb (7.11 here) on both
>> Solaris 9 and Solaris 10:
>>
>> $ gdb -q --batch -ex run selfkill{,-mt}
>>
>> ** Solaris 9, selfkill:
>>
>> Program received signal SIGINT, Interrupt.
>> 0xb5d54186 in _libc_kill () from /usr/lib/libc.so.1
>>
>> ** Solaris 9, selfkill-mt:
>>
>> [Thread debugging using libthread_db enabled]
>> [New Thread 1 (LWP 1)]
>> [New LWP 2 ]
>> [New Thread 2 (LWP 2)]
>>
>> Thread 2 received signal SIGINT, Interrupt.
>> [Switching to Thread 1 (LWP 1)]
>> 0xb5c9fad5 in _lwp_wait () from /usr/lib/libc.so.1
>>
>> ** Solaris 10, selfkill:
>>
>> [Thread debugging using libthread_db enabled]
>> [New Thread 1 (LWP 1)]
>>
>> Thread 2 received signal SIGINT, Interrupt.
>> [Switching to Thread 1 (LWP 1)]
>> 0xfef0c165 in kill () from /lib/libc.so.1
>>
>> ** Solaris 10, selfkill-mt:
>>
>> [Thread debugging using libthread_db enabled]
>> [New Thread 1 (LWP 1)]
>> [New LWP 2 ]
>> [New Thread 2 (LWP 2)]
>>
>> Thread 2 received signal SIGINT, Interrupt.
>> [Switching to Thread 1 (LWP 1)]
>> 0xfeedca05 in __lwp_wait () from /lib/libc.so.1
>>
>> ** Trying the same on Linux/x86_64, one sees the same behaviour as on
>> Solaris 9: non-threaded and threaded programs behave differently.
>>
>> * As you can see, on Solaris 10 even the not explicitly threaded version
>> of the test is shown as threaded, explaining the difference in the
>> "... received signal" messages.
>>
>> This is a consequence of the Thread Model Unification Project in
>> Solaris 10, which removed the difference between non-threaded and
>> threaded processes. This has nothing to do with the removal of the
>> pre-Solaris 9 MxN multilevel thread model as I'd originally
>> suspected.
>
> I tried to take a look at this a little. The only Solaris machines I
> have access to run on Sparc, not x86-64, but hopefully should still have
> much the same behaviour.
>
> I did manage to (eventually) build GDB on one of these machines, but,
> I'm not sure if I built it wrong, or if the Sparc/Solaris support is
> just bad, but GDB was crashing all over the place with assertion
> failures.
>
> Still, with some persistence I could see the behaviour you observe.
>
> Now, I've not done any Solaris work in >10years, so I don't claim to be
> any kind of expert, but I wonder if the fix you're proposing here isn't
> simply hiding a GDB bug.
>
> I wrote a simple test program that starts 3 worker threads and then
> blocks. Here's the 'info threads' output for GNU/Linux:
>
> (gdb) info threads
> Id Target Id Frame
> * 1 Thread 0x7ffff7da3740 (LWP 2243115) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
> 2 Thread 0x7ffff7da2700 (LWP 2243118) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
> 3 Thread 0x7ffff75a1700 (LWP 2243119) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
> 4 Thread 0x7ffff6da0700 (LWP 2243120) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
>
> What you'd expect. Now here's the same on Solaris:
>
> (gdb) info threads
> Id Target Id Frame
> * 1 LWP 1 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 2 LWP 4 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 3 LWP 3 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 4 LWP 2 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 5 Thread 1 (LWP 1) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 6 Thread 2 (LWP 2) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 7 Thread 3 (LWP 3) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 8 Thread 4 (LWP 4) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
>
> This is inline with what you describe, but, I think we can all agree,
> this seems a little odd; are there really 8 thread like things running
> as part of this process? The output of `ps -aL` would suggest not:
>
> $ ps -aL
> PID LWP TTY LTIME CMD
> 3855 1 pts/6 0:00 thr.x
> 3855 2 pts/6 0:00 thr.x
> 3855 3 pts/6 0:00 thr.x
> 3855 4 pts/6 0:00 thr.x
> 4132 1 pts/8 0:00 ps
>
> And also, when I run the same test application using the dbx debugger, I
> see this:
>
> (dbx) threads
> *> t@1 a l@1 ?() signal SIGINT in ___nanosleep()
> t@2 a l@2 thread_worker() running in ___nanosleep()
> t@3 a l@3 thread_worker() running in ___nanosleep()
> t@4 a l@4 thread_worker() running in ___nanosleep()
>
> So here, the process is represented as just 4 thread like things.
>
> So, why does GDB think there are 8, while every tools that ships with
> Solaris seems to think there are 4? My guess, is that is has something
> to do with the thread lookup code in sol-thread.c, and/or the operation
> of libthread-db.
>
> So, what I run your original selfkill test application, and use GDB to
> break on GDB's add_thread_with_info function (the thing that is
> responsible for printing the "New Thread ..." message), here's what I
> see:
>
> (gdb) bt
> #0 add_thread_with_info (targ=targ@entry=0x940678 <the_procfs_target>, ptid=..., priv=priv@entry=0x0) at ../../src/gdb/thread.c:290
> #1 0x0053b61c in add_thread (targ=0x940678 <the_procfs_target>, ptid=...) at ../../src/gdb/thread.c:305
> #2 0x004ab5f4 in sol_thread_target::wait (this=<optimized out>, ptid=..., ourstatus=0xffbff620, options=...) at ../../src/gdb/sol-thread.c:459
> #3 0x0053019c in target_wait (ptid=..., status=status@entry=0xffbff620, options=...) at ../../src/gdb/target.c:2598
> #4 0x00395478 in do_target_wait_1 (inf=inf@entry=0x969288, ptid=..., status=status@entry=0xffbff620, options=<error reading variable: Cannot access memory at address 0x0>) at ../../src/gdb/infrun.c:3763
> #5 0x003a7e8c in <lambda(inferior*)>::operator() (inf=0x969288, __closure=<synthetic pointer>) at ../../src/gdb/infrun.c:3822
> #6 do_target_wait (options=..., ecs=0xffbff600) at ../../src/gdb/infrun.c:3841
> #7 fetch_inferior_event () at ../../src/gdb/infrun.c:4201
> #8 0x001b0bd8 in check_async_event_handlers () at ../../src/gdb/async-event.c:337
> #9 0x006c4e3c in gdb_do_one_event (mstimeout=mstimeout@entry=-1) at ../../src/gdbsupport/event-loop.cc:221
> #10 0x003d7ea0 in start_event_loop () at ../../src/gdb/main.c:411
> #11 captured_command_loop () at ../../src/gdb/main.c:471
> #12 0x003d9fa8 in captured_main (data=0xffbff84c) at ../../src/gdb/main.c:1330
> #13 gdb_main (args=args@entry=0xffbff84c) at ../../src/gdb/main.c:1345
> #14 0x006f7c5c in main (argc=4, argv=0xffbff8bc) at ../../src/gdb/gdb.c:32
> (gdb) frame 2
> #2 0x004ab5f4 in sol_thread_target::wait (this=<optimized out>, ptid=..., ourstatus=0xffbff620, options=...) at ../../src/gdb/sol-thread.c:459
> 459 add_thread (proc_target, rtnval);
> (gdb) p rtnval
> $1 = {m_pid = 7218, m_lwp = 0, m_tid = 1}
> (gdb) p current_inferior_.m_obj->thread_list.m_front.ptid
> $2 = {m_pid = 7218, m_lwp = 1, m_tid = 0}
> (gdb)
>
> What this is telling us, is that, when GDB stopped after the ::wait
> call, the ptid_t it got back was '{m_pid = 7218, m_lwp = 0, m_tid = 1}',
> however, the original thread that GDB found when starting the
> application was '{m_pid = 7218, m_lwp = 1, m_tid = 0}'.
>
> This difference is what causes GDB to add the new thread.
>
> My guess is that this m_lwp/m_tid difference is a bug somewhere in the
> stack, and that really, we should be seeing the same ptid_t here. If we
> did, then GDB would not add the new thread, and the test messages would
> not change.
So, to clarify this a little, the discrepancy seems to arise from
lwp_to_thread, this is where we query libthread-db.
Before this point, in sol_thread_target::wait, we call:
ptid_t rtnval = beneath ()->wait (ptid, ourstatus, options);
this returns us the (maybe?) expected ptid_t {m_pid = 7218, m_lwp = 1,
m_tid = 0}, then when we call lwp_to_thread, we get back the alternative
ptid_t where the tid field is set, but the lwp field is not.
I don't know if this indicates a bug in libthread-db, or a bug in GDB.
Thanks,
Andrew
Hi Andrew,
> I tried to take a look at this a little. The only Solaris machines I
> have access to run on Sparc, not x86-64, but hopefully should still have
> much the same behaviour.
they do indeed. I agree it's a shame that no Solaris/x86 system (or
up-to-date Solaris 11.4/SPARC system) is part of the GCC compile farm,
but my attempt to provide this failed primarily for
administrative/university policy reasons.
> I did manage to (eventually) build GDB on one of these machines, but,
> I'm not sure if I built it wrong, or if the Sparc/Solaris support is
> just bad, but GDB was crashing all over the place with assertion
> failures.
It depends on your definition of `alll over the place', but yeah,
Solaris test results are pretty bad:
* sparcv9:
=== gdb Summary ===
# of unexpected core files 1
# of expected passes 68020
# of unexpected failures 3535
# of unexpected successes 13
# of expected failures 61
# of unknown successes 2
# of known failures 88
# of untested testcases 189
# of unresolved testcases 52
# of unsupported tests 244
# of paths in test names 12
# of duplicate test names 7
* amd64:
=== gdb Summary ===
# of unexpected core files 1
# of expected passes 72847
# of unexpected failures 2664
# of unexpected successes 13
# of expected failures 60
# of unknown successes 1
# of known failures 91
# of untested testcases 190
# of unresolved testcases 73
# of unsupported tests 254
# of paths in test names 13
# of duplicate test names 7
I had tried to attack the most glaring onces several times in the past,
but in the end it came to nothing: I really fear the complexity of the
GDB code base is beyond me for anything but fixing build failures and
minor feature patches ;-(
> Still, with some persistence I could see the behaviour you observe.
>
> Now, I've not done any Solaris work in >10years, so I don't claim to be
> any kind of expert, but I wonder if the fix you're proposing here isn't
> simply hiding a GDB bug.
>
> I wrote a simple test program that starts 3 worker threads and then
> blocks. Here's the 'info threads' output for GNU/Linux:
>
> (gdb) info threads
> Id Target Id Frame
> * 1 Thread 0x7ffff7da3740 (LWP 2243115) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
> 2 Thread 0x7ffff7da2700 (LWP 2243118) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
> 3 Thread 0x7ffff75a1700 (LWP 2243119) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
> 4 Thread 0x7ffff6da0700 (LWP 2243120) "thr.x" 0x00007ffff7e74215 in nanosleep () from /lib64/libc.so.6
>
> What you'd expect. Now here's the same on Solaris:
>
> (gdb) info threads
> Id Target Id Frame
> * 1 LWP 1 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 2 LWP 4 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 3 LWP 3 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 4 LWP 2 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 5 Thread 1 (LWP 1) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 6 Thread 2 (LWP 2) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 7 Thread 3 (LWP 3) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
> 8 Thread 4 (LWP 4) 0xfee4ddd4 in ___nanosleep () from /lib/libc.so.1
>
> This is inline with what you describe, but, I think we can all agree,
> this seems a little odd; are there really 8 thread like things running
> as part of this process? The output of `ps -aL` would suggest not:
>
> $ ps -aL
> PID LWP TTY LTIME CMD
> 3855 1 pts/6 0:00 thr.x
> 3855 2 pts/6 0:00 thr.x
> 3855 3 pts/6 0:00 thr.x
> 3855 4 pts/6 0:00 thr.x
> 4132 1 pts/8 0:00 ps
>
> And also, when I run the same test application using the dbx debugger, I
> see this:
>
> (dbx) threads
> *> t@1 a l@1 ?() signal SIGINT in ___nanosleep()
> t@2 a l@2 thread_worker() running in ___nanosleep()
> t@3 a l@3 thread_worker() running in ___nanosleep()
> t@4 a l@4 thread_worker() running in ___nanosleep()
>
> So here, the process is represented as just 4 thread like things.
>
> So, why does GDB think there are 8, while every tools that ships with
> Solaris seems to think there are 4? My guess, is that is has something
> to do with the thread lookup code in sol-thread.c, and/or the operation
> of libthread-db.
It certainly has, however the output is not really wrong, just
unnecessarily complex: As the head comment in sol-thread.c alludes to,
before Solaris 9 thread support in Solaris was implemented as a 2-level
model scheduling M user-level threads to N kernel threads/LWPs. The old
complexity is still visible in the info threads output above, which
lists both user-level threads and LWPs. However, with Solaris 9, this
all became obsolete with a 1:1 mapping from user-level threads to LWPs.
In fact, that new thread model was already visible in Solaris 8's
alternative thread library in /usr/lib/lwp, which gcc forcibly used
since it was the only one providing TLS support.
I tried at least once to rip out support for the two-level model from
sol-thread.c, but failed. While the output still isn't wrong, it's
plain confusing and especially the GDB testsuite isn't able to deal with
it, so it only causes problems.
linux-thread-db.c at some point implemented a similar two-level model,
but that has been ripped out since.
> So, what I run your original selfkill test application, and use GDB to
> break on GDB's add_thread_with_info function (the thing that is
> responsible for printing the "New Thread ..." message), here's what I
> see:
>
> (gdb) bt
> #0 add_thread_with_info (targ=targ@entry=0x940678 <the_procfs_target>, ptid=..., priv=priv@entry=0x0) at ../../src/gdb/thread.c:290
> #1 0x0053b61c in add_thread (targ=0x940678 <the_procfs_target>, ptid=...) at ../../src/gdb/thread.c:305
> #2 0x004ab5f4 in sol_thread_target::wait (this=<optimized out>, ptid=..., ourstatus=0xffbff620, options=...) at ../../src/gdb/sol-thread.c:459
> #3 0x0053019c in target_wait (ptid=..., status=status@entry=0xffbff620, options=...) at ../../src/gdb/target.c:2598
> #4 0x00395478 in do_target_wait_1 (inf=inf@entry=0x969288, ptid=..., status=status@entry=0xffbff620, options=<error reading variable: Cannot access memory at address 0x0>) at ../../src/gdb/infrun.c:3763
> #5 0x003a7e8c in <lambda(inferior*)>::operator() (inf=0x969288, __closure=<synthetic pointer>) at ../../src/gdb/infrun.c:3822
> #6 do_target_wait (options=..., ecs=0xffbff600) at ../../src/gdb/infrun.c:3841
> #7 fetch_inferior_event () at ../../src/gdb/infrun.c:4201
> #8 0x001b0bd8 in check_async_event_handlers () at ../../src/gdb/async-event.c:337
> #9 0x006c4e3c in gdb_do_one_event (mstimeout=mstimeout@entry=-1) at ../../src/gdbsupport/event-loop.cc:221
> #10 0x003d7ea0 in start_event_loop () at ../../src/gdb/main.c:411
> #11 captured_command_loop () at ../../src/gdb/main.c:471
> #12 0x003d9fa8 in captured_main (data=0xffbff84c) at ../../src/gdb/main.c:1330
> #13 gdb_main (args=args@entry=0xffbff84c) at ../../src/gdb/main.c:1345
> #14 0x006f7c5c in main (argc=4, argv=0xffbff8bc) at ../../src/gdb/gdb.c:32
> (gdb) frame 2
> #2 0x004ab5f4 in sol_thread_target::wait (this=<optimized out>, ptid=..., ourstatus=0xffbff620, options=...) at ../../src/gdb/sol-thread.c:459
> 459 add_thread (proc_target, rtnval);
> (gdb) p rtnval
> $1 = {m_pid = 7218, m_lwp = 0, m_tid = 1}
> (gdb) p current_inferior_.m_obj->thread_list.m_front.ptid
> $2 = {m_pid = 7218, m_lwp = 1, m_tid = 0}
> (gdb)
>
> What this is telling us, is that, when GDB stopped after the ::wait
> call, the ptid_t it got back was '{m_pid = 7218, m_lwp = 0, m_tid = 1}',
> however, the original thread that GDB found when starting the
> application was '{m_pid = 7218, m_lwp = 1, m_tid = 0}'.
>
> This difference is what causes GDB to add the new thread.
>
> My guess is that this m_lwp/m_tid difference is a bug somewhere in the
> stack, and that really, we should be seeing the same ptid_t here. If we
> did, then GDB would not add the new thread, and the test messages would
> not change.
>
> What are your thoughts on this analysis?
I do agree that this discrepancy is causing issues (certainly not only
here), but I've looked from a different angle:
the "<entity> received signal" message is from
infrun.c:print_signal_received_reason where the "Thread <id>" variant is
emitted if thread.c:show_thread_that_caused_stop returned true, which
happens for hightest_thread_num > 1. It could be (I do have long-winded
notes from long ago that I can only half make sense of now) that the
fact that both the user-level thread and the lwp are counted here cause
this.
It seems that highest_thead_num is incremented once from
Thread 2 hit Hardware watchpoint 3: 'thread.c'::highest_thread_num
Old value = 0
New value = 1
0x00000001009c83ec in thread_info::thread_info (this=0x100f8c100,
inf_=0x100f06670, ptid_=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:343
343 this->global_num = ++highest_thread_num;
(top-gdb) where
#0 0x00000001009c83ec in thread_info::thread_info (this=0x100f8c100,
inf_=0x100f06670, ptid_=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:343
#1 0x00000001009c8560 in new_thread (inf=0x100f06670, ptid=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:248
#2 0x00000001009cbd7c in add_thread_silent (ptid=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:310
#3 0x0000000100831604 in procfs_target::create_inferior (
this=0x100d138c0 <the_procfs_target>,
exec_file=0x100f13300 "/vol/obj/gnu/gdb/gdb/11.5-sparcv9-local/ua",
allargs="", env=0x100f06f80, from_tty=<optimized out>)
at /vol/src/gnu/gdb/hg/master/local/gdb/procfs.c:3093
and a second time from
Thread 2 hit Hardware watchpoint 3: 'thread.c'::highest_thread_num
Old value = 1
New value = 2
0x00000001009c83ec in thread_info::thread_info (this=0x101176ab0,
inf_=0x100f06670, ptid_=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:343
343 this->global_num = ++highest_thread_num;
(top-gdb) where
#0 0x00000001009c83ec in thread_info::thread_info (this=0x101176ab0,
inf_=0x100f06670, ptid_=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:343
#1 0x00000001009c8560 in new_thread (inf=0x100f06670, ptid=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:248
#2 0x00000001009cbd7c in add_thread_silent (ptid=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:310
#3 0x00000001009cbee4 in add_thread_with_info (ptid=..., priv=0x0)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:319
#4 0x00000001009cbfe0 in add_thread (ptid=...)
at /vol/src/gnu/gdb/hg/master/local/gdb/thread.c:333
#5 0x0000000100908b54 in sol_thread_target::wait (
this=0x100d1ba08 <sol_thread_ops>, ptid=..., ourstatus=<optimized out>,
options=<optimized out>)
at /vol/src/gnu/gdb/hg/master/local/gdb/sol-thread.c:466
#6 0x000000010099f9e4 in target_wait (ptid=..., status=0xffffffff7fffe460,
options=<optimized out>)
at /vol/src/gnu/gdb/hg/master/local/gdb/target.h:1298
#7 0x0000000100729228 in do_target_wait (ptid=..., status=0xffffffff7fffe460,
options=<optimized out>)
at /vol/src/gnu/gdb/hg/master/local/gdb/infrun.c:3442
#8 0x0000000100737e28 in fetch_inferior_event (client_data=0x0)
at /vol/src/gnu/gdb/hg/master/local/gdb/infrun.c:3725
#9 0x0000000100715210 in inferior_event_handler (event_type=<optimized out>, client_data=0x0) at /vol/src/gnu/gdb/hg/master/local/gdb/inf-loop.c:43
#10 0x00000001007273c4 in infrun_async_inferior_event_handler (data=0x0) at /vol/src/gnu/gdb/hg/master/local/gdb/infrun.c:8898
#11 0x0000000100691828 in check_async_event_handlers () at /vol/src/gnu/gdb/hg/master/local/gdb/event-loop.c:1062
#12 gdb_do_one_event () at /vol/src/gnu/gdb/hg/master/local/gdb/event-loop.c:325
#13 0x00000001006922ec in start_event_loop () at /vol/src/gnu/gdb/hg/master/local/gdb/event-loop.c:370
#14 0x0000000100786090 in captured_command_loop () at /vol/src/gnu/gdb/hg/master/local/gdb/main.c:331
#15 0x00000001007879fc in captured_main (data=<optimized out>) at /vol/src/gnu/gdb/hg/master/local/gdb/main.c:1171
#16 gdb_main (args=<optimized out>) at /vol/src/gnu/gdb/hg/master/local/gdb/main.c:1186
#17 0x0000000100470728 in main (argc=<optimized out>, argv=0xffffffff7fffeba8) at /vol/src/gnu/gdb/hg/master/local/gdb/gdb.c:32
As you see, those are old stacktraces and no longer match current code.
However, one call ultimately comes from procfs.c (i.e. for an lwp), the
second from sol-thread.c (for a user-level thread).
I strongly suspect this needs to go away, but don't have the slightest
idea how. Certainly, the whole thread/lwp distinction is moot since
Solaris 9: tid and lwpid are identical by now and there's a 1:1 mapping
between the two.
Rainer
Hi Andrew,
> So, to clarify this a little, the discrepancy seems to arise from
> lwp_to_thread, this is where we query libthread-db.
>
> Before this point, in sol_thread_target::wait, we call:
>
> ptid_t rtnval = beneath ()->wait (ptid, ourstatus, options);
>
> this returns us the (maybe?) expected ptid_t {m_pid = 7218, m_lwp = 1,
> m_tid = 0}, then when we call lwp_to_thread, we get back the alternative
> ptid_t where the tid field is set, but the lwp field is not.
>
> I don't know if this indicates a bug in libthread-db, or a bug in GDB.
I wouldn't suspect libthread_db itself, but rather the sol-thread.c
code. I guess I'll have to do a debug build of gdb and find what's
going on.
Rainer
# HG changeset patch
# Parent 83e8741eb69e875b4745b17494480e4271f0df40
Fix expected received signal message in testsuite
@@ -88,7 +88,7 @@ proc check_regs {regtype regnums value p
# Run until end of signal handler
gdb_test "continue" \
- "Continuing.*Program received signal SIGILL.*" \
+ "Continuing.*(Program|Thread .*) received signal SIGILL.*" \
"continue until signal"
gdb_breakpoint [gdb_get_line_number "exit(0)"]
@@ -32,7 +32,7 @@ gdb_run_cmd
set test "trap stop"
gdb_test_multiple "" $test {
- -re "Program received signal SIGTRAP,.*_start .*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGTRAP,.*_start .*$gdb_prompt $" {
pass $test
}
}
@@ -53,7 +53,7 @@ gdb_load ${binfile}
gdb_run_cmd
gdb_test_multiple {} "continue to abort()" {
- -re ".*Program received signal SIGABRT,.*$gdb_prompt $" {
+ -re ".*(Program|Thread .*) received signal SIGABRT,.*$gdb_prompt $" {
pass "continue to abort()"
}
}
@@ -57,7 +57,7 @@ set bndcfg_reg " = \\\{raw = $hex, confi
preserved = $hex, enabled = $hex\\\}\\\}"
set bndstatus_reg " = \\\{raw = $hex, status = \\\{bde = $hex,\
error = $hex\\\}\\\}"
-set u_fault [multi_line "Program received signal SIGSEGV, Segmentation fault" \
+set u_fault [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
"Upper bound violation while accessing address $hex" \
"Bounds: \\\[lower = $hex, upper = $hex\\\]"]
@@ -45,11 +45,11 @@ gdb_test_multiple "print have_mpx ()" "h
}
}
-set u_fault [multi_line "Program received signal SIGSEGV, Segmentation fault" \
+set u_fault [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
"Upper bound violation while accessing address $hex" \
"Bounds: \\\[lower = $hex, upper = $hex\\\]"]
-set l_fault [multi_line "Program received signal SIGSEGV, Segmentation fault" \
+set l_fault [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
"Lower bound violation while accessing address $hex" \
"Bounds: \\\[lower = $hex, upper = $hex\\\]"]
@@ -51,11 +51,11 @@ gdb_test_multiple "print have_mpx ()" "h
}
}
-set violation [multi_line "Program received signal SIGSEGV, Segmentation fault" \
+set violation [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault" \
"Upper bound violation while accessing address $hex" \
"Bounds: \\\[lower = $hex, upper = $hex\\\]"]
-set segv_with_exit "Program received signal SIGSEGV,\
+set segv_with_exit "(Program|Thread .*) received signal SIGSEGV,\
Segmentation fault.*$inferior_exited_re.*"
@@ -72,7 +72,7 @@ if ![runto_main] then {
# Testcase for standard prologue.
-gdb_test "continue" "Program received signal SIGTRAP.*" "continue to standard"
+gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to standard"
skip_breakpoint standard
@@ -99,7 +99,7 @@ gdb_test "backtrace 10" \
"first backtrace in stack_align_ecx"
gdb_test "continue" \
- "Program received signal SIGTRAP.*" \
+ "(Program|Thread .*) received signal SIGTRAP.*" \
"continue in stack_align_ecx"
skip_breakpoint stack_align_ecx
@@ -127,7 +127,7 @@ gdb_test "backtrace 10" \
"first backtrace in stack_align_edx"
gdb_test "continue" \
- "Program received signal SIGTRAP.*" \
+ "(Program|Thread .*) received signal SIGTRAP.*" \
"continue in stack_align_edx"
skip_breakpoint stack_align_edx
@@ -155,7 +155,7 @@ gdb_test "backtrace 10" \
"first backtrace in stack_align_eax"
gdb_test "continue" \
- "Program received signal SIGTRAP.*" \
+ "(Program|Thread .*) received signal SIGTRAP.*" \
"continue in stack_align_eax"
skip_breakpoint stack_align_eax
@@ -171,7 +171,7 @@ gdb_test "info frame" \
# Testcase from symtab/1253.
-gdb_test "continue" "Program received signal SIGTRAP.*" "continue to gdb1253"
+gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to gdb1253"
skip_breakpoint gdb1253
@@ -186,7 +186,7 @@ gdb_test "info frame" \
# Testcase from backtrace/1718.
-gdb_test "continue" "Program received signal SIGTRAP.*" "continue to gdb1718"
+gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to gdb1718"
skip_breakpoint gdb1718
@@ -202,7 +202,7 @@ gdb_test "info frame" \
# Testcase from backtrace/1338.
-gdb_test "continue" "Program received signal SIGTRAP.*" "continue to gdb1338"
+gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" "continue to gdb1338"
skip_breakpoint gdb1338
@@ -41,7 +41,7 @@ gdb_load ${binfile}
# We use gdb_run_cmd so this stands a chance to work for remote
# targets too.
gdb_run_cmd
-gdb_test "" "Program received signal SIGTRAP.*" "run past main"
+gdb_test "" "(Program|Thread .*) received signal SIGTRAP.*" "run past main"
set message "backtrace shows the outer function"
gdb_test_multiple "backtrace 10" $message {
@@ -46,7 +46,7 @@ gdb_load ${binfile}
# We use gdb_run_cmd so this stands a chance to work for remote
# targets too.
gdb_run_cmd
-gdb_test "" "Program received signal SIGTRAP.*" "run past main"
+gdb_test "" "(Program|Thread .*) received signal SIGTRAP.*" "run past main"
set message "backtrace shows no function"
gdb_test_multiple "backtrace 10" $message {
@@ -48,7 +48,7 @@ foreach i {0 1 2 3 4} {
-re " = 2\r\n$gdb_prompt $" {
pass $test
}
- -re "Program received signal SIGSEGV, Segmentation fault\\..*\r\n$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV, Segmentation fault\\..*\r\n$gdb_prompt $" {
fail $test
}
}
@@ -46,7 +46,7 @@ gdb_load ${binfile}
# We use gdb_run_cmd so this stands a chance to work for remote
# targets too.
gdb_run_cmd
-gdb_test "" "Program received signal SIGTRAP.*" "run past gdb1435"
+gdb_test "" "(Program|Thread .*) received signal SIGTRAP.*" "run past gdb1435"
gdb_test "backtrace 10" \
"#1\[ \t]*$hex in gdb1435.*\r\n#2\[ \t\]*$hex in main.*" \
@@ -31,7 +31,7 @@ gdb_run_cmd
set test "run until SIGSEGV"
gdb_test_multiple "" $test {
- -re "Program received signal SIGSEGV.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV.*$gdb_prompt $" {
pass $test
}
}
@@ -29,7 +29,7 @@ gdb_run_cmd
set test "run until SIGSEGV"
gdb_test_multiple "" $test {
- -re "Program received signal SIGSEGV.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV.*$gdb_prompt $" {
pass $test
}
}
@@ -41,7 +41,7 @@ if ![runto_main] then {
}
gdb_test_multiple "next" "check for TE support" {
- -re "Program received signal SIGILL,.*\r\n$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGILL,.*\r\n$gdb_prompt $" {
unsupported "no TE support."
return
}
@@ -59,7 +59,7 @@ set crashline [gdb_get_line_number "FAUL
gdb_test "print \$tdb0" "\\\$\[0-9\]+ = <unavailable>" "tdb0 unavailable"
gdb_test "print \$tr0" "\\\$\[0-9\]+ = <unavailable>" "tr0 unavailable"
gdb_test "next" \
- "Program received signal SIGSEGV, .*" \
+ "(Program|Thread .*) received signal SIGSEGV, .*" \
"crash in transaction"
gdb_test "print/x \$tdb0" "\\\$\[0-9\]+ = 0x1.*" "tdb0 available"
gdb_test "set print symbol-filename" "" "set print symbol-filename"
@@ -52,7 +52,7 @@ gdb_test_multiple "x/i \$pc" "get PC at
}
gdb_test_multiple "stepi" "check for vector support" {
- -re "Program received signal SIGILL,.*\r\n$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGILL,.*\r\n$gdb_prompt $" {
unsupported "no vector support."
return
}
@@ -48,6 +48,6 @@ gdb_test "adi x/100 shmaddr" "${hex}00:\
"examine new ADI"
gdb_test_no_output "adi a/100 shmaddr=0x0" "reset ADI"
gdb_test "continue" \
- [multi_line "Program received signal SIGSEGV, Segmentation fault.*" \
+ [multi_line "(Program|Thread .*) received signal SIGSEGV, Segmentation fault.*" \
"ADI precise mismatch while accessing address $hex.*" ] \
"continue to sigsegv"
@@ -126,7 +126,7 @@ set live_data [fetch_auxv "info auxv on
set gcore_works [gdb_gcore_cmd "$gcorefile" "gcore"]
# Let the program continue and die.
-gdb_test continue ".*Program received signal.*"
+gdb_test continue ".*(Program|Thread .*) received signal.*"
gdb_test continue ".*Program terminated with signal.*"
# Now collect the core dump it left.
@@ -84,7 +84,7 @@ proc do_test {} {
fail "$test (SIGALRM)"
return
}
- -re "Program received signal SIGINT.*\r\n$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGINT.*\r\n$gdb_prompt $" {
send_log "$internal_pass (SIGINT)\n"
}
-re "Quit\r\n$gdb_prompt $" {
@@ -134,7 +134,7 @@ proc test {always_inserted sw_watchpoint
unsupported "failed to stop at permanent breakpoint"
return
}
- -re "Program received signal SIGTRAP.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
pass $test
}
}
@@ -174,7 +174,7 @@ proc test {always_inserted sw_watchpoint
# disabled, it should act as if we hadn't created it in the first
# place. IOW, we should get a random signal, and, the breakpoint's
# command should not run.
- gdb_test "continue" "Program received signal SIGTRAP.*" \
+ gdb_test "continue" "(Program|Thread .*) received signal SIGTRAP.*" \
"disabled permanent breakpoint doesn't explain stop"
gdb_test "info breakpoints" \
@@ -257,7 +257,7 @@ proc test {always_inserted sw_watchpoint
set test "single-step to handler"
gdb_test_multiple "stepi" $test {
- -re "Program received signal SIGTRAP.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
fail $test
}
-re "handler .*$gdb_prompt $" {
@@ -105,7 +105,7 @@ gdb_test "continue" "Breakpoint \[0-9\]*
# Continue again, we should get a signal.
-gdb_test "continue" "Program received signal .*" \
+gdb_test "continue" "(Program|Thread .*) received signal .*" \
"continue to receipt of signal"
# Hand call another function that prematurely stops,
@@ -199,7 +199,7 @@ gdb_test_multiple "next" "step out of ma
-re "_*start\[0-9\]* \\(\[^)\]*\\).*$gdb_prompt $" {
pass "step out of main"
}
- -re ".*Program received signal SIGTRAP.*$gdb_prompt $" {
+ -re ".*(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
pass "step out of main"
}
-re ".*in.*__uClibc_main.*$gdb_prompt $" {
@@ -47,7 +47,7 @@ gdb_test "print \$_exitcode" " = void" \
"\$_exitcode is void before running"
# Trigger SIGSEGV.
-gdb_test "continue" "Program received signal SIGSEGV.*" "trigger SIGSEGV"
+gdb_test "continue" "(Program|Thread .*) received signal SIGSEGV.*" "trigger SIGSEGV"
# Continue until the end.
gdb_test "continue" "Program terminated with signal SIGSEGV.*" \
@@ -67,7 +67,7 @@ gdb_test_multiple $test $test {
set test "inferior received SIGINT"
gdb_test_multiple "" $test {
- -re "\r\nProgram received signal SIGINT.*" {
+ -re "\r\n(Program|Thread .*) received signal SIGINT.*" {
# This appears after the prompt, which was already consumed
# above.
pass $test
@@ -82,7 +82,7 @@ if ![file exists $binfile] then {
send_gdb "\003"
set msg "send_gdb control C"
gdb_test_multiple "" $msg {
- -re "Program received signal SIGINT.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGINT.*$gdb_prompt $" {
pass $msg
}
}
@@ -93,7 +93,7 @@ if ![file exists $binfile] then {
-re " = 4.*$gdb_prompt $" {
pass $msg
}
- -re ".*Program received signal SIG(SEGV|ILL).*$gdb_prompt $" {
+ -re ".*(Program|Thread .*) received signal SIG(SEGV|ILL).*$gdb_prompt $" {
setup_xfail "i*86-pc-linux*-gnu*"
fail "child died when we called func1, skipped rest of tests"
return
@@ -166,7 +166,7 @@ if ![file exists $binfile] then {
set msg "Send Control-C, second time"
send_gdb "\003"
gdb_test_multiple "" "$msg" {
- -re "Program received signal SIGINT.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGINT.*$gdb_prompt $" {
pass "$msg"
}
}
@@ -111,7 +111,7 @@ proc jit_reader_test {} {
gdb_test_no_output "jit-reader-load ${jit_reader_bin}" "jit-reader-load"
gdb_run_cmd
- gdb_test "" "Program received signal SIGTRAP, .*" "expect SIGTRAP"
+ gdb_test "" "(Program|Thread .*) received signal SIGTRAP, .*" "expect SIGTRAP"
# Test the JIT reader unwinder.
with_test_prefix "with jit-reader" {
@@ -35,7 +35,7 @@ if ![runto_main] {
return -1
}
-gdb_test "continue" "Program received signal SIGUSR1, .*"
+gdb_test "continue" "(Program|Thread .*) received signal SIGUSR1, .*"
gdb_test "stepi" "\r\nhandler .*"
gdb_test_multiple "kill" "kill" {
-re "Kill the program being debugged\\? \\(y or n\\) $" {
@@ -47,7 +47,7 @@ proc do_test {} {
# For this to work we must be sure to consume the "Continuing."
# message first, or GDB's signal handler may not be in place.
after 500 {send_gdb "\003"}
- gdb_test "" "Program received signal SIGINT.*" "stop with control-c"
+ gdb_test "" "(Program|Thread .*) received signal SIGINT.*" "stop with control-c"
}
# With native debugging and "run" (with job control), the ctrl-c
@@ -193,7 +193,7 @@ if ![target_info exists gdb,nointerrupts
incr vcont_r_counter
exp_continue
}
- -re "Program received signal SIGINT.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGINT.*$gdb_prompt $" {
pass $test
}
}
@@ -43,7 +43,7 @@ gdb_test_multiple $test $test {
}
# pause () -> SIGALRM -> handler () -> abort ()
-gdb_test "continue" "Program received signal SIGABRT.*"
+gdb_test "continue" "(Program|Thread .*) received signal SIGABRT.*"
# Backtracing through pause broke if glibc has been prelinked,
# because the separate debug files in /usr/lib/debug had different
@@ -50,7 +50,7 @@ proc test_one_sig {nextsig} {
}
gdb_test "continue" \
- "Continuing.*Program received signal SIG$esig.*" \
+ "Continuing.*(Program|Thread .*) received signal SIG$esig.*" \
"get signal $esig"
}
@@ -180,7 +180,7 @@ gdb_test "handle SIGTERM stop print" \
"SIGTERM\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes.*"
gdb_test "b handle_TERM" "Breakpoint \[0-9\]+ .*"
gdb_test "continue" \
- "Continuing.*Program received signal SIGTERM.*" \
+ "Continuing.*(Program|Thread .*) received signal SIGTERM.*" \
"get signal TERM"
gdb_test "continue" "Breakpoint.*handle_TERM.*" "send signal TERM"
gdb_continue_to_end "continue to sigall exit"
@@ -76,9 +76,9 @@ gdb_test "advance bowler" "bowler.*" "ad
set test "stepping to fault"
set signame "SIGSEGV"
gdb_test_multiple "stepi" "$test" {
- -re "Program received signal (SIGBUS|SIGSEGV).*pc(\r\n| *) *=> (0x\[0-9a-f\]*).*$gdb_prompt $" {
- set signame $expect_out(1,string)
- set segv_addr $expect_out(3,string)
+ -re "(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*pc(\r\n| *) *=> (0x\[0-9a-f\]*).*$gdb_prompt $" {
+ set signame $expect_out(2,string)
+ set segv_addr $expect_out(4,string)
pass "$test"
}
-re " .*pc(\r\n| *)=> (0x\[0-9a-f\]*).*bowler.*$gdb_prompt $" {
@@ -171,7 +171,7 @@ proc stepi_out { name args } {
send_gdb "stepi\n"
exp_continue
}
- -re "Program received signal SIGSEGV.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV.*$gdb_prompt $" {
kfail gdb/8807 "$test (executed fault insn)"
}
-re "Breakpoint.*pc(\r\n| *)[at_segv] .*bowler.*$gdb_prompt $" {
@@ -236,7 +236,7 @@ proc cont_out { name args } {
# Now single step the faulted instrction at that breakpoint.
gdb_test "stepi" \
- "Program received signal ${signame}.*pc(\r\n| *)=> [at_segv] .*" \
+ "(Program|Thread .*) received signal ${signame}.*pc(\r\n| *)=> [at_segv] .*" \
"${name}; stepi fault"
# Clear any breakpoints
@@ -40,7 +40,7 @@ if ![runto_main] then {
}
# Run to the signal.
-gdb_test "continue" ".*Program received signal SIGSEGV.*" "continue to signal"
+gdb_test "continue" ".*(Program|Thread .*) received signal SIGSEGV.*" "continue to signal"
gdb_breakpoint "pass"
@@ -31,7 +31,7 @@ if ![runto_main] {
gdb_breakpoint "pass"
gdb_breakpoint "fail"
-gdb_test "continue" "Program received signal SIGUSR1, .*" "continue to SIGUSR1"
+gdb_test "continue" "(Program|Thread .*) received signal SIGUSR1, .*" "continue to SIGUSR1"
gdb_test "p callme ()" " = 42"
@@ -45,7 +45,7 @@ if ![runto_main] then {
}
# Run to the signal.
-gdb_test "continue" ".*Program received signal SIGSEGV.*" "continue to signal"
+gdb_test "continue" ".*(Program|Thread .*) received signal SIGSEGV.*" "continue to signal"
# Try to generate a core file, for a later test.
set gcorefile [standard_output_file $testfile.gcore]
@@ -104,7 +104,7 @@ if ![runto_main] then {
}
# Run to the signal.
-gdb_test "continue" ".*Program received signal SIGSEGV.*" "continue to signal"
+gdb_test "continue" ".*(Program|Thread .*) received signal SIGSEGV.*" "continue to signal"
set test "set si_addr"
gdb_test "p \$_siginfo._sifields._sigfault.si_addr = 0x666" " = \\(void \\*\\) 0x666"
@@ -44,7 +44,7 @@ if { [is_address_zero_readable] } {
# Run until we hit the SIGSEGV (or SIGBUS on some platforms).
gdb_test "continue" \
- ".*Program received signal (SIGBUS|SIGSEGV).*bowler.*" \
+ ".*(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*bowler.*" \
"continue to fault"
# Insert conditional breakpoint at faulting instruction
@@ -56,6 +56,6 @@ gdb_test "handle SIGBUS nostop print pas
# Step off the faulting instruction into the handler, triggering nested faults
gdb_test "continue" \
- ".*Program received signal (SIGBUS|SIGSEGV).*Program received signal (SIGBUS|SIGSEGV).*exited normally.*" \
+ ".*(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*(Program|Thread .*) received signal (SIGBUS|SIGSEGV).*exited normally.*" \
"run through nested faults"
@@ -72,14 +72,14 @@ set test "probe function pointer"
set function_pointer code_entry_point
set signame "SIGSEGV"
gdb_test_multiple "continue" "$test" {
- -re "Program received signal SIGSEGV.*bowler .*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV.*bowler .*$gdb_prompt $" {
set function_pointer code_descriptor
pass "$test (function descriptor)"
}
- -re "Program received signal SIGSEGV.*0.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV.*0.*$gdb_prompt $" {
pass "$test (function entry-point)"
}
- -re "Program received signal SIGBUS.*0.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGBUS.*0.*$gdb_prompt $" {
set signame SIGBUS
pass "$test (function entry-point)"
}
@@ -103,7 +103,7 @@ proc test_segv { name tag bt_from_segv b
gdb_test continue "Breakpoint.* bowler.*" "${name}; start with the bowler"
# NB: Don't use $tag in the testname - changes across systems.
gdb_test_no_output "set test = $tag" "${name}; select the pointer type"
- gdb_test continue "Program received signal ${signame}.*" \
+ gdb_test continue "(Program|Thread .*) received signal ${signame}.*" \
"${name}; take the ${signame}"
gdb_test backtrace $bt_from_segv "${name}; backtrace from ${signame}"
gdb_test continue "Breakpoint.* keeper.*" "${name}; continue to the keeper"
@@ -91,7 +91,7 @@ proc advance { enter_cmd in_handler_pref
} else {
gdb_test "handle SIGALRM print pass stop"
gdb_test "handle SIGVTALRM print pass stop"
- gdb_test "continue" "Program received signal.*" "continue to signal"
+ gdb_test "continue" "(Program|Thread .*) received signal.*" "continue to signal"
}
gdb_test "$enter_cmd" ".*handler .*" "$enter_cmd to handler"
@@ -150,7 +150,7 @@ set in_handler_map {
set test "advance in handler"
gdb_test_multiple "advance $other_handler_location" $test {
- -re "Program received signal SIGTRAP.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGTRAP.*$gdb_prompt $" {
# On some versions of Linux (observed on
# 3.16.4-200.fc20.x86_64), using PTRACE_SINGLESTEP+sig
# to step into a signal handler, and then issuing
@@ -34,7 +34,7 @@ if ![runto_main] {
# trace the test code
gdb_test_no_output "record btrace"
gdb_test "continue" [multi_line \
- "Program received signal SIGSEGV, Segmentation fault\." \
+ "(Program|Thread .*) received signal SIGSEGV, Segmentation fault\." \
"0x0* in \\\?\\\? \\\(\\\)" \
] "cont to segv"
@@ -53,10 +53,10 @@ proc test_one_sig {nextsig} {
}
set testmsg "get signal $thissig"
gdb_test_multiple "continue" $testmsg {
- -re "Program received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
fail "$testmsg (wrong location)"
}
- -re "Program received signal SIG$thissig.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIG$thissig.*$gdb_prompt $" {
pass $testmsg
}
-re "Breakpoint.* handle_$thissig.*$gdb_prompt $" {
@@ -114,7 +114,7 @@ proc test_one_sig_reverse {prevsig} {
-re "Breakpoint.*handle_.*$gdb_prompt " {
pass "$testmsg (un-handled)"
}
- -re "Program received signal SIG$prevsig.*$gdb_prompt " {
+ -re "(Program|Thread .*) received signal SIG$prevsig.*$gdb_prompt " {
pass "reverse to signal event, $prevsig"
set nested_testmsg "reverse signal delivered"
@@ -299,7 +299,7 @@ gdb_test "handle SIGTERM stop print" \
"SIGTERM\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes.*"
gdb_test "b handle_TERM" "Breakpoint \[0-9\]+ .*"
gdb_test "continue" \
- "Continuing.*Program received signal SIGTERM.*" \
+ "Continuing.*(Program|Thread .*) received signal SIGTERM.*" \
"get signal TERM"
gdb_test "continue" "Breakpoint.*handle_TERM.*" "send signal TERM"
@@ -52,10 +52,10 @@ proc test_one_sig {nextsig} {
}
set testmsg "get signal $thissig"
gdb_test_multiple "continue" $testmsg {
- -re "Program received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIG$thissig.*handle_$thissig.*$gdb_prompt $" {
fail "$testmsg (wrong location)"
}
- -re "Program received signal SIG$thissig.*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIG$thissig.*$gdb_prompt $" {
pass $testmsg
}
-re "Breakpoint.* handle_$thissig.*$gdb_prompt $" {
@@ -113,7 +113,7 @@ proc test_one_sig_reverse {prevsig} {
-re "Breakpoint.*handle_.*$gdb_prompt " {
pass "$testmsg (un-handled)"
}
- -re "Program received signal SIG$prevsig.*$gdb_prompt " {
+ -re "(Program|Thread .*) received signal SIG$prevsig.*$gdb_prompt " {
pass "reverse to signal event, $prevsig"
set nested_testmsg "reverse signal delivered"
@@ -247,7 +247,7 @@ gdb_test "handle SIGTERM stop print" \
"SIGTERM\[ \t\]*Yes\[ \t\]*Yes\[ \t\]*Yes.*"
gdb_test "b handle_TERM" "Breakpoint \[0-9\]+ .*"
gdb_test "continue" \
- "Continuing.*Program received signal SIGTERM.*" \
+ "Continuing.*(Program|Thread .*) received signal SIGTERM.*" \
"get signal TERM"
gdb_test "continue" "Breakpoint.*handle_TERM.*" "send signal TERM"
@@ -58,7 +58,7 @@ proc connect_continue_ctrl_c {} {
}
after 1000 {send_gdb "\003"}
- gdb_test "" "Program received signal SIGINT.*" "stop with control-c"
+ gdb_test "" "(Program|Thread .*) received signal SIGINT.*" "stop with control-c"
}
with_test_prefix "first" {
@@ -99,7 +99,7 @@ foreach nonstop { 0 1 } { with_test_pref
}
}
- gdb_test "continue" "Program received signal SIGUSR1, .*"
+ gdb_test "continue" "(Program|Thread .*) received signal SIGUSR1, .*"
gdb_test "sharedlibrary" ".*"
gdb_test "p libvar" " = 23"
}}
@@ -99,7 +99,7 @@ proc test_tracepoints { trace_command co
-re ".*Breakpoint \[0-9\]+, end .*$gdb_prompt $" {
pass "advance through tracing"
}
- -re "Program received signal SIGSEGV, Segmentation fault\\..*$gdb_prompt $" {
+ -re "(Program|Thread .*) received signal SIGSEGV, Segmentation fault\\..*$gdb_prompt $" {
if { $kfail_proc != 0 } {
$kfail_proc $trace_command
}