Re: [cdt-dev] Support for "target-detach" and "target-disconnect"

[Pedro Alves <pedro@xxxxxxxxxxxxxxxx>]

To (try to) clarify things from GDB's perpective:

 - "disconnect" disconnects from the (remote) target.  It literaly just removes
   breakpoints and closes the socket.  The target is supposed to leave
   its processes/threads however they were (most usually stopped) so that
   a new GDB can reconnect and resume debugging.

 - "detach" tells the target to detach the current process (at the
   OS/debug API level, this always sets the process running free, and
   so when gdb evolved into the embedded world, this behaviour ended
   up engraved, and expected to be emulated by embedded debug stubs).
   GDB's "target remote" target always _also_ disconnects if it is no
   longer controlling a process --- that is, just after detach, kill,
   or when the program exits).  This target does not support
   multi-process, and is the target most often used with embedded
   debugging.  "target extended-remote" (note the "extended-"), or
   native gdb debugging do not implicitly do this disconnection; you continue
   connected to the target, and can do further "attach" and "run"s, etc.

These are different use cases.  In the former you're interested
in resuming debugging, in the latter, you're not.

Simply replacing "detach" by "resume all threads" + "disconnect" is
_not_ the same thing.  E.g., a linux gdbserver will _not_ detach
itself from its inferior processes if GDB disconnects from it.
There are other issues; one example: between the frontend telling
the debugger to to resume everything and telling it to disconnect,
what if a signal arrives to the inferior and is reported to
the frontend?  At disconnect time, you'd end up with
the thread that reported the signal stopped.  You'd have to instead do:
 "please-remove-all-breakpoints-and-put-yourself-in-a-mode-that-forwards-all-signals-and-events-back-to-the-debuggee-as-if-you-were-no-longer-attached" + 
 "resume all threads" +
 "disconnect"

Detaching always handles this in the debugger.  It takes care of
forwarding pending events back to the debuggee, and leaving things
consistent.

-- 
Pedro Alves