* [PATCH] testsuite: Persistent gdbserver cleanup
@ 2013-10-23 22:59 Maciej W. Rozycki
2013-10-24 19:36 ` Pedro Alves
0 siblings, 1 reply; 3+ messages in thread
From: Maciej W. Rozycki @ 2013-10-23 22:59 UTC (permalink / raw)
To: gdb-patches
Hi,
We have a number of tests that run `gdbserver' in the persistent mode, to
be able to disconnect and reconnect. That has a side effect of leaving
the `gdbserver' behind upon GDB termination at the conclusion of the
respective test cases, because no kill request is sent to `gdbserver' at
the end of session and as a result of receiving a KILL signal GDB merely
disconnects.
This causes problems in some remote test environments, such as QEMU in
the system emulation mode, where `gdbserver' is run within Linux run on
QEMU and QEMU's TCP port forwarding feature is used to communicate with
the `gdbserver'. In this case a single TCP port is used to talk to
`gdbserver' and a subsequent test case faces `gdbserver' still running
controlling the program used for the test case that has just concluded.
Killing off that `gdbserver' process, while possible, is complicated and
I think test cases should try to leave the state clean if possible, so
here's my proposal to make the harness explicitly request `gdbserver' to
terminate before killing off GDB where the persistent mode has been
requested. Additionally one test case terminated GDB in a disconnected
state, so I made it reconnect before completion.
No regressions in mips-linux-gnu testing. OK to apply?
2013-10-23 Maciej W. Rozycki <macro@codesourcery.com>
gdb/testsuite/
* lib/gdb.exp (gdb_finish): Send a kill request to `gdbserver'
if in the persistent mode.
* gdb.trace/disconnected-tracing.exp: Reconnect before completion.
Maciej
gdb-test-gdbserver-reconnect-kill.diff
Index: gdb-fsf-trunk-quilt/gdb/testsuite/gdb.trace/disconnected-tracing.exp
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/testsuite/gdb.trace/disconnected-tracing.exp 2013-10-17 22:42:31.578765350 +0100
+++ gdb-fsf-trunk-quilt/gdb/testsuite/gdb.trace/disconnected-tracing.exp 2013-10-17 22:44:53.117689854 +0100
@@ -147,3 +147,6 @@ proc disconnected_tfind { } {
}
disconnected_tfind
+
+# Reconnect for a clean gdbserver shutdown.
+gdb_reconnect
Index: gdb-fsf-trunk-quilt/gdb/testsuite/lib/gdb.exp
===================================================================
--- gdb-fsf-trunk-quilt.orig/gdb/testsuite/lib/gdb.exp 2013-10-17 22:44:51.618780708 +0100
+++ gdb-fsf-trunk-quilt/gdb/testsuite/lib/gdb.exp 2013-10-17 22:44:53.117689854 +0100
@@ -3612,8 +3612,23 @@ proc gdb_init { args } {
}
proc gdb_finish { } {
+ global gdbserver_reconnect_p
+ global gdb_prompt
global cleanfiles
+ # Give persistent gdbserver a chance to terminate before GDB is killed.
+ if {[info exists gdbserver_reconnect_p] && $gdbserver_reconnect_p} {
+ send_gdb "kill\n";
+ gdb_expect 10 {
+ -re "y or n" {
+ send_gdb "y\n";
+ exp_continue;
+ }
+ -re "$gdb_prompt $" {
+ }
+ }
+ }
+
# Exit first, so that the files are no longer in use.
gdb_exit
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] testsuite: Persistent gdbserver cleanup
2013-10-23 22:59 [PATCH] testsuite: Persistent gdbserver cleanup Maciej W. Rozycki
@ 2013-10-24 19:36 ` Pedro Alves
2013-10-24 22:37 ` Maciej W. Rozycki
0 siblings, 1 reply; 3+ messages in thread
From: Pedro Alves @ 2013-10-24 19:36 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: gdb-patches
On 10/23/2013 11:59 PM, Maciej W. Rozycki wrote:
> Hi,
>
> We have a number of tests that run `gdbserver' in the persistent mode, to
> be able to disconnect and reconnect. That has a side effect of leaving
> the `gdbserver' behind upon GDB termination at the conclusion of the
> respective test cases, because no kill request is sent to `gdbserver' at
> the end of session and as a result of receiving a KILL signal GDB merely
> disconnects.
>
> This causes problems in some remote test environments, such as QEMU in
> the system emulation mode, where `gdbserver' is run within Linux run on
> QEMU and QEMU's TCP port forwarding feature is used to communicate with
> the `gdbserver'. In this case a single TCP port is used to talk to
> `gdbserver' and a subsequent test case faces `gdbserver' still running
> controlling the program used for the test case that has just concluded.
>
> Killing off that `gdbserver' process, while possible, is complicated and
> I think test cases should try to leave the state clean if possible, so
> here's my proposal to make the harness explicitly request `gdbserver' to
> terminate before killing off GDB where the persistent mode has been
> requested. Additionally one test case terminated GDB in a disconnected
> state, so I made it reconnect before completion.
>
> No regressions in mips-linux-gnu testing. OK to apply?
Seems OK.
Though I think this won't work in extended-remote mode, where
"kill" won't actually bring down gdbserver. I think we'd need to use
"monitor exit" for that instead. (I think we'd do that with a new
gdbserver_finish hook in gdbserver-support.exp that instead of
hardcoding that gdbserver-specific command in gdb_finish). But it's fine
with me if you don't want to fix that.
--
Pedro Alves
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] testsuite: Persistent gdbserver cleanup
2013-10-24 19:36 ` Pedro Alves
@ 2013-10-24 22:37 ` Maciej W. Rozycki
0 siblings, 0 replies; 3+ messages in thread
From: Maciej W. Rozycki @ 2013-10-24 22:37 UTC (permalink / raw)
To: Pedro Alves; +Cc: gdb-patches
On Thu, 24 Oct 2013, Pedro Alves wrote:
> > We have a number of tests that run `gdbserver' in the persistent mode, to
> > be able to disconnect and reconnect. That has a side effect of leaving
> > the `gdbserver' behind upon GDB termination at the conclusion of the
> > respective test cases, because no kill request is sent to `gdbserver' at
> > the end of session and as a result of receiving a KILL signal GDB merely
> > disconnects.
> >
> > This causes problems in some remote test environments, such as QEMU in
> > the system emulation mode, where `gdbserver' is run within Linux run on
> > QEMU and QEMU's TCP port forwarding feature is used to communicate with
> > the `gdbserver'. In this case a single TCP port is used to talk to
> > `gdbserver' and a subsequent test case faces `gdbserver' still running
> > controlling the program used for the test case that has just concluded.
> >
> > Killing off that `gdbserver' process, while possible, is complicated and
> > I think test cases should try to leave the state clean if possible, so
> > here's my proposal to make the harness explicitly request `gdbserver' to
> > terminate before killing off GDB where the persistent mode has been
> > requested. Additionally one test case terminated GDB in a disconnected
> > state, so I made it reconnect before completion.
> >
> > No regressions in mips-linux-gnu testing. OK to apply?
>
> Seems OK.
Applied now, thanks for your review.
> Though I think this won't work in extended-remote mode, where
> "kill" won't actually bring down gdbserver. I think we'd need to use
> "monitor exit" for that instead. (I think we'd do that with a new
> gdbserver_finish hook in gdbserver-support.exp that instead of
> hardcoding that gdbserver-specific command in gdb_finish). But it's fine
> with me if you don't want to fix that.
Hmm, it looks like you're right, however `gdbserver_run' seems to rely on
`kill' already regardless of the mode selected. I'm not sure how it's
supposed to work though given that at this point the instance of GDB that
was possibly connected to `gdbserver' has already been killed. Perhaps
some target board configs don't kill GDB between test cases, though myself
I have yet to see one.
Anyway, I think you are in a better position to fix up all this mess. I
haven't ever used the extended-remote mode even.
Maciej
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-10-24 22:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-23 22:59 [PATCH] testsuite: Persistent gdbserver cleanup Maciej W. Rozycki
2013-10-24 19:36 ` Pedro Alves
2013-10-24 22:37 ` Maciej W. Rozycki
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).