GitLab

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>

Reviewed-by: hjk

Reviewed-By: hjk

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

if the respective view is enabled, the manager will request the
initial update in some unholy state, probably AdapterStarting -
when gdb isn't up yet.

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.

there seems to be no reason for delaying the display because
of -break-list

doesn't seem to serve any purpose at this time.

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.

- 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

first, try harder to have an up-to-date sources list.
then, use the mapping whenever applicable and available.

*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 ...

in theory, we should support fsf gdb on apple now.
this also cleans and documents some execution paths.

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

This should save debugger round trips and crashes in the debugging
helpers.
Add respective option to debugging helper option page, defaulting to
true.On this occasion, make CDB detect shadowed variables correctly
and display them as "<shadowed n>" as does the Gdb engine by
reversing the direction in which
CdbSymbolGroupContext::populateINameIndexMap works.
Rubber-stamped-by: hjk <qtc-committer@nokia.com>

after refactoring the trk adapter startup, the split was not necessary
any more. in fact, it seemed fairly arbitrary at this point.

it is currently unused. do not just remove it, as hjk says he wants to
revive it.

each command can have only one of two legitimate responses: "error" or -
depending on the command, and thus declared via a flag - "done" or
"running".
this is way nicer than sprinkling the code with else-ifs (where elses
are sufficient) and asserts all over the place - and silently failing in
release builds.

For the case that gdb can give all the interesting data in one go.

this drastically improves the usefulness of the debugger output window
by making internal and external messages appear in sync.

fixes build

Add a configuration checking method to the Debugger manager,
depending on toolchain, wire it to the engines.
Check that in the debugger run controls.

Add a convenience method to ICore that shows a warning
message with a "Settings" button, pointing the user
to a configuration error on a settings page.

Remove leftovers of the dumper parser.
Acked-by: con <qtc-committer@nokia.com>