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

[Pedro Alves <pedro@codesourcery.com>]

Sorry, I forgot an important detail in the explanations below.  Hope the
below makes it clearer.

On Tuesday 14 October 2008 23:03:28, Pedro Alves wrote:
> 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

      <insert "killall gdbserver" here>

>  (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]

      <insert "killall gdbserver" here>

>  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