From: Tom de Vries <tdevries@suse.de>
To: Pedro Alves <pedro@palves.net>, gdb-patches@sourceware.org
Subject: Re: [PATCH][gdb/testsuite] Detect gdb prompt after monitor exit
Date: Wed, 16 Sep 2020 14:55:33 +0200 [thread overview]
Message-ID: <69e90e69-6d42-b76d-ba56-9742731c4906@suse.de> (raw)
In-Reply-To: <98ef5ad6-3a12-7dc9-1561-b46758f39c8f@palves.net>
[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]
On 9/16/20 12:59 PM, Pedro Alves wrote:
> On 9/15/20 3:17 PM, Tom de Vries wrote:
>
>> Anyway, this seems to work:
>> ...
>> index a2cc80f28d..24733275ae 100644
>> --- a/gdb/testsuite/lib/gdbserver-support.exp
>> +++ b/gdb/testsuite/lib/gdbserver-support.exp
>> @@ -451,13 +451,20 @@ proc gdbserver_exit { is_mi } {
>> # We use expect rather than gdb_expect because
>> # we want to suppress printing exception messages, otherwise,
>> # remote_expect, invoked by gdb_expect, prints the exceptions.
>> + set have_prompt 0
>> expect {
>> -i "$gdb_spawn_id" -re "$gdb_prompt $" {
>> - exp_continue
>> + if { [info exists server_spawn_id] } {
>> + set have_prompt 1
>
> I'd put this "set have_prompt 1" outside of the if, seems would read
> clearer to me.
>
Done.
> Otherwise LGTM.
>
>> + exp_continue
>> + }
>> }
>> -i "$server_spawn_id" eof {
>> wait -i $expect_out(spawn_id)
>> unset server_spawn_id
>> + if { ! $have_prompt } {
>> + exp_continue
>> + }
>> }
>> timeout {
>> warning "Timed out waiting for EOF in server after
>> $monitor_exit"
>> ...
>>
>> I do wonder though about unsetting server_spawn_id and doing
>> exp_continue while we still have the clause -i $server_spawn_id eof. I
>> wonder this is supported behaviour.
>
> I'm not super sure, but I think it is, in that I don't think
> the -i expression is reevaluated after exp_continue.
>
> For example, this works:
>
> $ cat exp.exp
> set fake_spawn_id foo
>
> expect {
> -re "foo" {
> puts " got foo"
> if [info exists fake_spawn_id] {
> puts " unset"
> unset fake_spawn_id
> }
> exp_continue
> }
> -i "$fake_spawn_id" -re "bar" {
> puts " got bar?"
> }
> }
>
> $ expect exp.exp
> foo
> got foo
> unset
> foo
> got foo
> foo
> got foo
> bar
> foo
> got foo
>
> If it turns out to be an issue, we can always use an indirect
> spawn id instead:
>
> "The -i flag may also name a global variable in which case the variable is read for a list of spawn ids. The variable is reread
> whenever it changes. This provides a way of changing the I/O source while the command is in execution. Spawn ids provided this way
> are called "indirect" spawn ids. "
OK, then let's try it like this for now.
Committed as attached.
Thanks,
- Tom
[-- Attachment #2: 0001-gdb-testsuite-Detect-gdb-prompt-after-monitor-exit.patch --]
[-- Type: text/x-patch, Size: 2720 bytes --]
[gdb/testsuite] Detect gdb prompt after monitor exit
With this gdbserver-support.exp patch:
...
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } {
# We use expect rather than gdb_expect because
# we want to suppress printing exception messages, otherwise,
# remote_expect, invoked by gdb_expect, prints the exceptions.
+ set have_prompt 0
expect {
-i "$gdb_spawn_id" -re "$gdb_prompt $" {
+ set have_prompt 1
exp_continue
}
-i "$server_spawn_id" eof {
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
warning "Timed out waiting for EOF in server after $monitor_exit"
}
}
+ gdb_assert {$have_prompt}
}
}
close_gdbserver
...
and with this in parallel:
...
$ stress -c 5
...
we run into this and similar FAILs:
...
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $have_prompt
...
In more detail:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
Remote debugging from host ::1, port 40712^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target \
created; pid = 11098^M
monitor exit^M
Killing process(es): 11098^M
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $have_prompt
spawn build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory \
build/gdb/testsuite/../data-directory^M
...
After issuing a "monitor exit" command, we should always get a prompt back, so
check for that.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-09-16 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdbserver_exit): Make sure we
get the gdb prompt after issuing "monitor exit".
---
gdb/testsuite/lib/gdbserver-support.exp | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/gdb/testsuite/lib/gdbserver-support.exp b/gdb/testsuite/lib/gdbserver-support.exp
index a2cc80f28d..2734ca6c87 100644
--- a/gdb/testsuite/lib/gdbserver-support.exp
+++ b/gdb/testsuite/lib/gdbserver-support.exp
@@ -451,13 +451,20 @@ proc gdbserver_exit { is_mi } {
# We use expect rather than gdb_expect because
# we want to suppress printing exception messages, otherwise,
# remote_expect, invoked by gdb_expect, prints the exceptions.
+ set have_prompt 0
expect {
-i "$gdb_spawn_id" -re "$gdb_prompt $" {
- exp_continue
+ set have_prompt 1
+ if { [info exists server_spawn_id] } {
+ exp_continue
+ }
}
-i "$server_spawn_id" eof {
wait -i $expect_out(spawn_id)
unset server_spawn_id
+ if { ! $have_prompt } {
+ exp_continue
+ }
}
timeout {
warning "Timed out waiting for EOF in server after $monitor_exit"
prev parent reply other threads:[~2020-09-16 12:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 19:21 Tom de Vries
2020-09-15 13:05 ` Pedro Alves
2020-09-15 14:17 ` Tom de Vries
2020-09-16 10:59 ` Pedro Alves
2020-09-16 12:55 ` Tom de Vries [this message]
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=69e90e69-6d42-b76d-ba56-9742731c4906@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=pedro@palves.net \
/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