those pesky nested event loops ...
i pondered various other scenarios (in particular, the adapter or
gdb crashing while the nested loop is running), but did not discover
serious side effects of it, so i'm not trying to handle it specially.
this isn't bullet-proof - integrated error messages are already
translated. but at least we know *where* the message comes from.
also, saves the translators from some pretty useless work.
- Remove old rfcomm process handler from TrkGdbAdapter, use
Bluetooth starter instead
- Synchronous connection, remove waitForTrkConnect()
- Move gdb start into Trk version answer, pass on
settings id hint
- Prevent exit crash triggered by signal gdbProcessFinished()
- Set DebuggerNotReady correctly on AdapterStartFailed when no
gdb is started yet
seems to have been an artifact from an early version. it was
unreachable (gdb going wild notwithstanding), and would do
Strange Stuff (TM) if it ever were reached.
*in theory*, there is no way we could at any point know more than gdb
knows and tells us about full path names. let's see what practice shows
for the gdbs we support ...
these missed the handleExecContinue() callback, so they got missed last
time. added both callback and flag, and some more glue to the gross
isBogus hack.
as it turns out, it is not possible to set pending breakpoints until
gdb has loaded as image. so add some hooks to enable adapters to trigger
the initial breakpoint syncing at the right time. do not add additional
states (say, InferiorPreparing), as it would just complicate things.
this includes:
- move the gdb ownership back to the engine (thus strip down the
adaptors as far as possible)
- make gdb startup synchronous
- make adapter shutdown synchronous
- fix the state transitions relating to shutdown
Includes Maemo tool chain, run configuration, run control,
manager, etc.
Adds the DebuggerManager to the object pool. This is ugly, but
nobody came up with anything better on short notice. To be
refactored.
Co-Authored-By: kh1
On UNIX, use SIGINT to interrupt the child, as the remote debugger's
-exec-interrupt does so as well.
On Windows, we get a SIGTRAP which we cannot influence.
As we currently do not know on which OS a remote debuggee is running,
accept either signal in that mode.
Reviewed-By: ossi
