public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: Bernd Edlinger <bernd.edlinger@hotmail.de>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix random dejagnu test abort with simulator target
Date: Fri, 19 Apr 2024 18:30:37 +0200	[thread overview]
Message-ID: <52bbb92c-5bf1-4c1f-a89c-6de46be82dd5@suse.de> (raw)
In-Reply-To: <AS8P193MB12854225ABE612F040C43CF3E40D2@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM>

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.


  reply	other threads:[~2024-04-19 16:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-19 10:49 Bernd Edlinger
2024-04-19 13:26 ` Tom de Vries
2024-04-19 14:19   ` Bernd Edlinger
2024-04-19 16:30     ` Tom de Vries [this message]
2024-04-19 20:21       ` Bernd Edlinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52bbb92c-5bf1-4c1f-a89c-6de46be82dd5@suse.de \
    --to=tdevries@suse.de \
    --cc=bernd.edlinger@hotmail.de \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).