[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-debug-dev] Terminate debug session for embedded development
|
>
> This is a writeup to check if there is a consensus amongst embedded
> developers w.r.t. what is needed in terms of a terminate debug session.
>
> I believe that CDT has a Terminate debug session concept that is much
> more complex than is needed for the common case embedded development.
> This problem is made worse by GDB frequently being unresponsive due to
> either GDB or JTAG debugger issues.
>
> The complexities are due to support for multiple debug targets/processes
> in a single debug session.=20
>
> The problem is that concepts are introduced before the embedded
> developer needs them to solve problems.
>
> Basically what most embedded developers want is to either:
>
> 1. detach the debug session from the target and let the target
> continue execution
> 2. kill the GDB process immediately without caring what happens=20
> to the debug target afterwards.
>
> In the Debug view, it is possible to select various "Terminate" and
> "Terminate and remove" actions depending on which object is selected.
> They each mean different things. When GDB is stuck, I just try them
> all :-)
>
The Terminate action will differ from the selection:
- if the selection is the DebugTarget/DebugThread/StackFrame:
the terminate will be sent to the debugtarget only ...
This behaviour is for debug session that have multiple target(for example
doing follow-fork(), so a session can have n targets). However to help the user
CDT will also close the session, if there is no other targets.
In theory:
debugTarget.terminate();
if (debugSession.getDebugTargets().length == 0) {
debugSession.terminate();
}
- if the selection is the DebugSession:
equivalent:
for (int i = 0; i < debugTargets.length; ++i) {
debutTargets.terminate();
}
debugSession.terminate();
Terminate && Remove is an eclipse thing, until you do the remove, you can still see
the log of the output console.
Of course the problem is .. Sometimes, gdb does not respond to
debugTarget.terminate() nor debugSession.terminate().
> What I would like to see is all the existing low-level terminate
> concepts for single-target common case embedded development removed and
> replaced with two actions:
>
> - Detach debugger from target
> - Terminate debug session. GDB is terminated by the
> a-kind-word-and-a-gun principle. It is told to quit nicely and given
> two seconds before it is terminated using all possible means provided=20
> by nasty native OS code.
>
Agreed, for this it should be handle in the backend of the debugger.
debugSession.terminate() means ... finish/kaput/dead/over/flatline and we go through
the drill i.e. Process.destroy() ... but on some system "gdb a` la peau dure"
i.e. the thing is hard to kill.