PATCH: really close the extended-remote target if we lose the connection

[Pedro Alves]

Check out this difference between target remote, and target extended-remote:

target remote:

 >./gdb /home/pedro/gdb/tests/threads32
 GNU gdb (GDB) 6.8.50.20081014-cvs
 [...]
 (gdb) tar remote :9999
 Remote debugging using :9999
 0xf7fbb810 in ?? () from /lib/ld-linux.so.2
 (gdb) info threads
 Remote connection closed
 (gdb) maint print target-stack
 The current target stack is:
   - exec (Local exec file)
   - None (None)
 (gdb) q
 [nothing]

target extended-remote:

 >./gdb /home/pedro/gdb/tests/threads32
 GNU gdb (GDB) 6.8.50.20081014-cvs
 [...]
 (gdb) tar extended-remote :9999
 Remote debugging using :9999
 0xf7f70810 in ?? () from /lib/ld-linux.so.2
 (gdb) c
 Continuing.
 [Switching to Thread 22227]
 Remote connection closed
 (gdb) info threads
 putpkt: write failed: Broken pipe.
 (gdb)  
 
 (gdb) maint print target-stack
 The current target stack is:
   - extended-remote (Extended remote serial target in gdb-specific protocol)
   - exec (Local exec file)
   - None (None)
 (gdb)
 
 (gdb) q
 The program is running.  Quit anyway (and kill it)? (y or n) y
 Quitting: putpkt: write failed: Broken pipe.

The issue is again the mixup of "target" as in
'interface'/'debug api'/'connection to system', vs "target" as in "inferior".

In the remote target, a target_mourn_inferior unpushes the target_ops,
while in the extended-remote target, it doesn't, leaving the user with
a useless broken connection.

The attached patch makes the extended-remote behave the same as the
remote target.  Considering an extended-remote connection debugging
multi-processes seems to make it clearer that target_mourn_inferior
isn't the right call here, me thinks.

There are cases in async mode that when the connection was broken,
we'd leave the SIGINT signal handler set to handle_remote_sigint or
handle_remote_sigint_twice, although we had already poped the target,
which would result in later crashes.  I'm also making sure in remote_close
that that doesn't happen.

Any objections to this?

No regressions on x86_64-unknown-linux-gnu (sync/async).

-- 
Pedro Alves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remote_close.diff
Type: text/x-diff
Size: 3991 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20081014/85909238/attachment.bin>