The real problems is somewhere in the watch model. This patch does
only prevent the wrong (and unneeded) questions to be asked in the first
place. It does not fix the wrong handling of the answer in the watch model.
Reviewed-by: Oswald Buddenhagen
sometimes, commands simply don't return ...
the debug message doesn't say anything which couldn't be found in the
log already, but that way it is more convenient.
and we kill gdb to get creator back to a defined state.
Reviewed-by: hjk
on UNIX. Either set the LD_PRELOAD environment variable
using a gdb command or have the TermGdbAdapter set the
variable for the debuggee. For the remote adapter,
switch on toolchain. dlopen() is a fallback for
platforms where it is not supported and attaching
to running processes. Fixes a crash with gdb 7.0
(and spurious gdb 6.8 crashes with dlopen()).
Reviewed-by: hjk <qtc-committer@nokia.com>
first, _start being resolvable depends on libc-dbg being installed.
second, depending on the frame being in the dynloader makes it
a) work only for dynamic executables and b) fail on multi-target
systems (due to a hard-coded file name).
so instead just remember the entry point, as we are already there
anyway.
Reviewed-By: hjk
the assumption is that pending breakpoints will only be resolved when
the source list changes. consequently it is pointless to update just
one of them.
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 ...
