Re: [PATCH] testsuite: Persistent gdbserver cleanup

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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