Fix random dejagnu test abort with simulator target
Checks
Context |
Check |
Description |
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gdb_build--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gdb_check--master-arm |
success
|
Testing passed
|
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 |
success
|
Testing passed
|
Commit Message
This is probably a dejagnu issue with the gdb testsuite
when a simulator target is used. I observed random
testrun aborts with dejagnu 1.6.2-1 from ubuntu 20.04
The problem starts when the test case gdb.base/sigwinch-notty.exp
tries to execute "sleep", although that is impossible with a
simulator. And for unknown reason the test case completes
(with errors) before the "after 1000" block is run.
Then in a totally different test this happens with 50% likelihood:
ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
The error code is TCL LOOKUP COMMAND bgerror
The info on the error is:
invalid command name "bgerror"
while executing
"::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"
=== gdb Summary ===
# of expected passes 30815
# of unexpected failures 241
# of expected failures 3
# of known failures 23
# of unresolved testcases 241
# of untested testcases 96
# of unsupported tests 532
# of paths in test names 1
So the whole test run is aborted in the middle.
This patch should fix the issue.
---
gdb/testsuite/gdb.base/sigwinch-notty.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On 4/19/24 12:49, Bernd Edlinger wrote:
> This is probably a dejagnu issue with the gdb testsuite
> when a simulator target is used. I observed random
> testrun aborts with dejagnu 1.6.2-1 from ubuntu 20.04
> The problem starts when the test case gdb.base/sigwinch-notty.exp
> tries to execute "sleep", although that is impossible with a
> simulator. And for unknown reason the test case completes
> (with errors) before the "after 1000" block is run.
>
> Then in a totally different test this happens with 50% likelihood:
>
> ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
> The error code is TCL LOOKUP COMMAND bgerror
> The info on the error is:
> invalid command name "bgerror"
> while executing
> "::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
> ("uplevel" body line 1)
> invoked from within
> "uplevel 1 ::tcl_unknown $args"
>
> === gdb Summary ===
>
> # of expected passes 30815
> # of unexpected failures 241
> # of expected failures 3
> # of known failures 23
> # of unresolved testcases 241
> # of untested testcases 96
> # of unsupported tests 532
> # of paths in test names 1
>
> So the whole test run is aborted in the middle.
>
> This patch should fix the issue.
> ---
> gdb/testsuite/gdb.base/sigwinch-notty.exp | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/sigwinch-notty.exp b/gdb/testsuite/gdb.base/sigwinch-notty.exp
> index cef21c07c59..0f70f0978d2 100644
> --- a/gdb/testsuite/gdb.base/sigwinch-notty.exp
> +++ b/gdb/testsuite/gdb.base/sigwinch-notty.exp
> @@ -21,7 +21,7 @@ require {!target_info exists gdb,nosignals}
>
> # The testfile relies on "run" from the command line, so only works
> # with "target native".
> -if { [target_info gdb_protocol] != "" } {
> +if { [target_info gdb_protocol] != "" || [target_info is_simulator] != ""} {
> return
> }
>
Hi Bernd,
thanks for the report and patch.
[ I ran the test-case using make-check-all.sh, and ran into trouble with
host/target board local-remote-host-native.
I added some debugging here:
...
verbose -log "gdb_spawn_id=$gdb_spawn_id"
verbose -log "gdb_pid=$gdb_pid"
+verbose -log "gdb_pid: [exec ps -p $gdb_pid]"
...
and first ran with the default target board unix:
...
gdb_spawn_id=exp6
gdb_pid=28288
gdb_pid: PID TTY TIME CMD
28288 pts/3 00:00:00 notty-wrap
...
and then with host+target local-remote-host-native:
...
gdb_spawn_id=exp6
gdb_pid=27827
gdb_pid: PID TTY TIME CMD
27827 pts/3 00:00:00 ssh
...
Which is basically the remote host variant of what's explained here for
remote target:
...
proc can_spawn_for_attach { } {
# We use exp_pid to get the inferior's pid, assuming that gives
# back the pid of the program. On remote boards, that would give
# us instead the PID of e.g., the ssh client, etc.
if {[is_remote target]} {
verbose -log "can't spawn for attach (target is remote)"
return 0
}
...
Anyway, this can be fixed using:
...
-if { [target_info gdb_protocol] != "" } {
+if { [target_info gdb_protocol] != "" || [is_remote host] } {
...
]
Back to the problem you reported.
I wonder about using gdb_spawn without checking for the result. Does it
still reproduce if we bail out when gdb_spawn fails?
If so, can you show the actual gdb.log for the test-case?
Thanks,
- Tom
On 4/19/24 15:26, Tom de Vries wrote:
> On 4/19/24 12:49, Bernd Edlinger wrote:
>> This is probably a dejagnu issue with the gdb testsuite
>> when a simulator target is used. I observed random
>> testrun aborts with dejagnu 1.6.2-1 from ubuntu 20.04
>> The problem starts when the test case gdb.base/sigwinch-notty.exp
>> tries to execute "sleep", although that is impossible with a
>> simulator. And for unknown reason the test case completes
>> (with errors) before the "after 1000" block is run.
>>
>> Then in a totally different test this happens with 50% likelihood:
>>
>> ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
>> The error code is TCL LOOKUP COMMAND bgerror
>> The info on the error is:
>> invalid command name "bgerror"
>> while executing
>> "::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
>> ("uplevel" body line 1)
>> invoked from within
>> "uplevel 1 ::tcl_unknown $args"
>>
>> === gdb Summary ===
>>
>> # of expected passes 30815
>> # of unexpected failures 241
>> # of expected failures 3
>> # of known failures 23
>> # of unresolved testcases 241
>> # of untested testcases 96
>> # of unsupported tests 532
>> # of paths in test names 1
>>
>> So the whole test run is aborted in the middle.
>>
>> This patch should fix the issue.
>> ---
>> gdb/testsuite/gdb.base/sigwinch-notty.exp | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/sigwinch-notty.exp b/gdb/testsuite/gdb.base/sigwinch-notty.exp
>> index cef21c07c59..0f70f0978d2 100644
>> --- a/gdb/testsuite/gdb.base/sigwinch-notty.exp
>> +++ b/gdb/testsuite/gdb.base/sigwinch-notty.exp
>> @@ -21,7 +21,7 @@ require {!target_info exists gdb,nosignals}
>> # The testfile relies on "run" from the command line, so only works
>> # with "target native".
>> -if { [target_info gdb_protocol] != "" } {
>> +if { [target_info gdb_protocol] != "" || [target_info is_simulator] != ""} {
>> return
>> }
>>
>
> Hi Bernd,
>
> thanks for the report and patch.
>
> [ I ran the test-case using make-check-all.sh, and ran into trouble with host/target board local-remote-host-native.
>
> I added some debugging here:
> ...
> verbose -log "gdb_spawn_id=$gdb_spawn_id"
> verbose -log "gdb_pid=$gdb_pid"
> +verbose -log "gdb_pid: [exec ps -p $gdb_pid]"
> ...
> and first ran with the default target board unix:
> ...
> gdb_spawn_id=exp6
> gdb_pid=28288
> gdb_pid: PID TTY TIME CMD
> 28288 pts/3 00:00:00 notty-wrap
> ...
> and then with host+target local-remote-host-native:
> ...
> gdb_spawn_id=exp6
> gdb_pid=27827
> gdb_pid: PID TTY TIME CMD
> 27827 pts/3 00:00:00 ssh
> ...
>
> Which is basically the remote host variant of what's explained here for remote target:
> ...
> proc can_spawn_for_attach { } {
> # We use exp_pid to get the inferior's pid, assuming that gives
> # back the pid of the program. On remote boards, that would give
> # us instead the PID of e.g., the ssh client, etc.
> if {[is_remote target]} {
> verbose -log "can't spawn for attach (target is remote)"
> return 0
> }
> ...
>
> Anyway, this can be fixed using:
> ...
> -if { [target_info gdb_protocol] != "" } {
> +if { [target_info gdb_protocol] != "" || [is_remote host] } {
> ...
> ]
>
> Back to the problem you reported.
>
> I wonder about using gdb_spawn without checking for the result. Does it still reproduce if we bail out when gdb_spawn fails?
>
> If so, can you show the actual gdb.log for the test-case?
>
Sure,
testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigstep.exp completed in 0 seconds
Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigwinch-notty.exp ...
Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sigwinch-notty (timeout = 300)
builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sigwinch-notty^M
builtin_spawn /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/lib/notty-wrap /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory -ex show editing -ex run --args sleep 3^M
gdb_spawn_id=exp9
gdb_pid=79294
^M
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration^M
of GDB. Attempting to continue with the default riscv settings.^M
^M
Reading symbols from sleep...^M
(No debugging symbols found in sleep)^M
Editing of command lines as they are typed is off.^M
Don't know how to run. Try "help target".^M
(gdb) FAIL: gdb.base/sigwinch-notty.exp: wait for sleep exit
GDB process exited with wait status 79294 exp9 0 0
PASS: gdb.base/sigwinch-notty.exp: wait for gdb exit
testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigwinch-notty.exp completed in 0 seconds
Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sizeof.exp ...
Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof (timeout = 300)
builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof^M
Executing on host: riscv-unknown-elf-gcc -fno-stack-protector -fdiagnostics-color=never -c -g -o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof/sizeof0.o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sizeof.c (timeout = 300)
builtin_spawn -ignore SIGHUP riscv-unknown-elf-gcc -fno-stack-protector -fdiagnostics-color=never -c -g -o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof/sizeof0.o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sizeof.c^M
[and a few 1000 lines later]
uiltin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/so-impl-ld^M
UNSUPPORTED: gdb.base/so-impl-ld.exp: require failed: allow_shlib_tests
testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.exp completed in 0 seconds
Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-abort.exp ...
Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/solib-abort (timeout = 300)
builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/solib-abort^M
ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
The error code is TCL LOOKUP COMMAND bgerror
The info on the error is:
invalid command name "bgerror"
while executing
"::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::tcl_unknown $args"
=== gdb Summary ===
# of expected passes 30817
# of unexpected failures 241
# of expected failures 3
# of known failures 23
# of unresolved testcases 241
# of untested testcases 96
# of unsupported tests 527
# of paths in test names 1
Executing on host: /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory --version (timeout = 300)
builtin_spawn -ignore SIGHUP /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory --version^M
GNU gdb (GDB) 15.0.50.20240419-git^M
Copyright (C) 2024 Free Software Foundation, Inc.^M
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>^M
This is free software: you are free to change and redistribute it.^M
There is NO WARRANTY, to the extent permitted by law.^M
/home/ed/gnu/binutils-build-riscv-1/gdb/gdb version 15.0.50.20240419-git -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory
looks like this is the spawned gdb?
Thanks
Bernd.
On 4/19/24 16:19, Bernd Edlinger wrote:
> On 4/19/24 15:26, Tom de Vries wrote:
>> On 4/19/24 12:49, Bernd Edlinger wrote:
>>> This is probably a dejagnu issue with the gdb testsuite
>>> when a simulator target is used. I observed random
>>> testrun aborts with dejagnu 1.6.2-1 from ubuntu 20.04
>>> The problem starts when the test case gdb.base/sigwinch-notty.exp
>>> tries to execute "sleep", although that is impossible with a
>>> simulator. And for unknown reason the test case completes
>>> (with errors) before the "after 1000" block is run.
>>>
>>> Then in a totally different test this happens with 50% likelihood:
>>>
>>> ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
>>> The error code is TCL LOOKUP COMMAND bgerror
>>> The info on the error is:
>>> invalid command name "bgerror"
>>> while executing
>>> "::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
>>> ("uplevel" body line 1)
>>> invoked from within
>>> "uplevel 1 ::tcl_unknown $args"
>>>
>>> === gdb Summary ===
>>>
>>> # of expected passes 30815
>>> # of unexpected failures 241
>>> # of expected failures 3
>>> # of known failures 23
>>> # of unresolved testcases 241
>>> # of untested testcases 96
>>> # of unsupported tests 532
>>> # of paths in test names 1
>>>
>>> So the whole test run is aborted in the middle.
>>>
>>> This patch should fix the issue.
>>> ---
>>> gdb/testsuite/gdb.base/sigwinch-notty.exp | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gdb/testsuite/gdb.base/sigwinch-notty.exp b/gdb/testsuite/gdb.base/sigwinch-notty.exp
>>> index cef21c07c59..0f70f0978d2 100644
>>> --- a/gdb/testsuite/gdb.base/sigwinch-notty.exp
>>> +++ b/gdb/testsuite/gdb.base/sigwinch-notty.exp
>>> @@ -21,7 +21,7 @@ require {!target_info exists gdb,nosignals}
>>> # The testfile relies on "run" from the command line, so only works
>>> # with "target native".
>>> -if { [target_info gdb_protocol] != "" } {
>>> +if { [target_info gdb_protocol] != "" || [target_info is_simulator] != ""} {
>>> return
>>> }
>>>
>>
>> Hi Bernd,
>>
>> thanks for the report and patch.
>>
>> [ I ran the test-case using make-check-all.sh, and ran into trouble with host/target board local-remote-host-native.
>>
>> I added some debugging here:
>> ...
>> verbose -log "gdb_spawn_id=$gdb_spawn_id"
>> verbose -log "gdb_pid=$gdb_pid"
>> +verbose -log "gdb_pid: [exec ps -p $gdb_pid]"
>> ...
>> and first ran with the default target board unix:
>> ...
>> gdb_spawn_id=exp6
>> gdb_pid=28288
>> gdb_pid: PID TTY TIME CMD
>> 28288 pts/3 00:00:00 notty-wrap
>> ...
>> and then with host+target local-remote-host-native:
>> ...
>> gdb_spawn_id=exp6
>> gdb_pid=27827
>> gdb_pid: PID TTY TIME CMD
>> 27827 pts/3 00:00:00 ssh
>> ...
>>
>> Which is basically the remote host variant of what's explained here for remote target:
>> ...
>> proc can_spawn_for_attach { } {
>> # We use exp_pid to get the inferior's pid, assuming that gives
>> # back the pid of the program. On remote boards, that would give
>> # us instead the PID of e.g., the ssh client, etc.
>> if {[is_remote target]} {
>> verbose -log "can't spawn for attach (target is remote)"
>> return 0
>> }
>> ...
>>
>> Anyway, this can be fixed using:
>> ...
>> -if { [target_info gdb_protocol] != "" } {
>> +if { [target_info gdb_protocol] != "" || [is_remote host] } {
>> ...
>> ]
>>
>> Back to the problem you reported.
>>
>> I wonder about using gdb_spawn without checking for the result. Does it still reproduce if we bail out when gdb_spawn fails?
>>
>
>> If so, can you show the actual gdb.log for the test-case?
>>
>
> Sure,
>
> testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigstep.exp completed in 0 seconds
> Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigwinch-notty.exp ...
> Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sigwinch-notty (timeout = 300)
> builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sigwinch-notty^M
> builtin_spawn /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/lib/notty-wrap /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory -ex show editing -ex run --args sleep 3^M
> gdb_spawn_id=exp9
> gdb_pid=79294
> ^M
> warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration^M
> of GDB. Attempting to continue with the default riscv settings.^M
> ^M
> Reading symbols from sleep...^M
> (No debugging symbols found in sleep)^M
> Editing of command lines as they are typed is off.^M
> Don't know how to run. Try "help target".^M
OK, I see now.
We spawn gdb on host to spawn sleep on target.
So I get to:
...
# The test-case relies on "run" from the command line, so it only works
# with "target native", so we need host == target.
#
# The test-case uses "exp_pid -i $gdb_spawn_id" which doesn't work with
# remote host, so we need build == host.
#
# In other words, we need build == host == target.
require {!is_remote host} {!is_remote target}
# Check that we have "target native" as opposed to native-gdbserver etc.
require {string equal [target_info gdb_protocol] ""}
...
Having said that, I'm not sure if that addresses your problem, since I
don't have experience with simulator setups.
Perhaps "require isnative" is also necessary for simulators? That proc
seems to check for target triplet == build triplet, while I think we're
more interested in target triplet == host triplet, but it may be a
sufficient proxy.
Thanks,
- Tom
> (gdb) FAIL: gdb.base/sigwinch-notty.exp: wait for sleep exit
> GDB process exited with wait status 79294 exp9 0 0
> PASS: gdb.base/sigwinch-notty.exp: wait for gdb exit
> testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigwinch-notty.exp completed in 0 seconds
> Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sizeof.exp ...
> Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof (timeout = 300)
> builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof^M
> Executing on host: riscv-unknown-elf-gcc -fno-stack-protector -fdiagnostics-color=never -c -g -o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof/sizeof0.o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sizeof.c (timeout = 300)
> builtin_spawn -ignore SIGHUP riscv-unknown-elf-gcc -fno-stack-protector -fdiagnostics-color=never -c -g -o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sizeof/sizeof0.o /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sizeof.c^M
>
> [and a few 1000 lines later]
>
> uiltin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/so-impl-ld^M
> UNSUPPORTED: gdb.base/so-impl-ld.exp: require failed: allow_shlib_tests
> testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.exp completed in 0 seconds
> Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/solib-abort.exp ...
> Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/solib-abort (timeout = 300)
> builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/solib-abort^M
> ERROR: (DejaGnu) proc "bgerror {can't read "gdb_pid": no such variable}" does not exist.
> The error code is TCL LOOKUP COMMAND bgerror
> The info on the error is:
> invalid command name "bgerror"
> while executing
> "::tcl_unknown bgerror {can't read "gdb_pid": no such variable}"
> ("uplevel" body line 1)
> invoked from within
> "uplevel 1 ::tcl_unknown $args"
>
> === gdb Summary ===
>
> # of expected passes 30817
> # of unexpected failures 241
> # of expected failures 3
> # of known failures 23
> # of unresolved testcases 241
> # of untested testcases 96
> # of unsupported tests 527
> # of paths in test names 1
> Executing on host: /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory --version (timeout = 300)
> builtin_spawn -ignore SIGHUP /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory --version^M
> GNU gdb (GDB) 15.0.50.20240419-git^M
> Copyright (C) 2024 Free Software Foundation, Inc.^M
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>^M
> This is free software: you are free to change and redistribute it.^M
> There is NO WARRANTY, to the extent permitted by law.^M
> /home/ed/gnu/binutils-build-riscv-1/gdb/gdb version 15.0.50.20240419-git -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /home/ed/gnu/binutils-build-riscv-1/gdb/data-directory
>
> looks like this is the spawned gdb?
>
> Thanks
> Bernd.
On 4/19/24 18:30, Tom de Vries wrote:
>
> OK, I see now.
>
> We spawn gdb on host to spawn sleep on target.
>
> So I get to:
> ...
> # The test-case relies on "run" from the command line, so it only works
> # with "target native", so we need host == target.
> #
> # The test-case uses "exp_pid -i $gdb_spawn_id" which doesn't work with
> # remote host, so we need build == host.
> #
> # In other words, we need build == host == target.
> require {!is_remote host} {!is_remote target}
>
> # Check that we have "target native" as opposed to native-gdbserver etc.
> require {string equal [target_info gdb_protocol] ""}
> ...
>
> Having said that, I'm not sure if that addresses your problem, since I don't have experience with simulator setups.
>
> Perhaps "require isnative" is also necessary for simulators? That proc seems to check for target triplet == build triplet, while I think we're more interested in target triplet == host triplet, but it may be a sufficient proxy.
>
hmm...
[target_info is_simulator] is explicitly set for simulators.
see /usr/share/dejagnu/baseboards/basic-sim.exp:
set_board_info is_simulator 1
I use RUNTESTFLAGS="--target_board=multi-sim"
I tried your suggested change, and it worked for me:
--- a/gdb/testsuite/gdb.base/sigwinch-notty.exp
+++ b/gdb/testsuite/gdb.base/sigwinch-notty.exp
@@ -19,11 +19,17 @@
require {!target_info exists gdb,nosignals}
-# The testfile relies on "run" from the command line, so only works
-# with "target native".
-if { [target_info gdb_protocol] != "" || [target_info is_simulator] != ""} {
- return
-}
+# The test-case relies on "run" from the command line, so it only works
+# with "target native", so we need host == target.
+#
+# The test-case uses "exp_pid -i $gdb_spawn_id" which doesn't work with
+# remote host, so we need build == host.
+#
+# In other words, we need build == host == target.
+require {!is_remote host} {!is_remote target}
+
+# Check that we have "target native" as opposed to native-gdbserver etc.
+require {string equal [target_info gdb_protocol] ""}
gdb_exit
Running /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigwinch-notty.exp ...
Executing on build: rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sigwinch-notty (timeout = 300)
builtin_spawn -ignore SIGHUP rm -rf /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/outputs/gdb.base/sigwinch-notty^M
UNSUPPORTED: gdb.base/sigwinch-notty.exp: require failed: !is_remote target
testcase /home/ed/gnu/binutils-build-riscv-1/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/sigwinch-notty.exp completed in 0 seconds
so that would be acceptable.
Thanks
Bernd.
@@ -21,7 +21,7 @@ require {!target_info exists gdb,nosignals}
# The testfile relies on "run" from the command line, so only works
# with "target native".
-if { [target_info gdb_protocol] != "" } {
+if { [target_info gdb_protocol] != "" || [target_info is_simulator] != ""} {
return
}