[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Support for "target-detach" and "target-disconnect"
|
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