GitLab

Reviewed-by: hjk <qtc-committer@nokia.com>
Reviewed-by: dt <qtc-committer@nokia.com>

Reviewed-by: dt

InferiorUnrunnable is equivalent to InferiorStopped as far as NeedsStop
commands are concerned.

Reviewed-by: hjk

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

Reviewed-by: hjk <qtc-committer@nokia.com>

Reviewed-by: hjk <qtc-committer@nokia.com>

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

Reviewed-by: hjk

Reviewed-by: hjk

Reviewed-by: dt <qtc-committer@nokia.com>

This reverts commit c069cd58.

Directly enable project explorer actions.
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

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

... - in the source view, that is. so grey them out in the stack view.

Reviewed-By: hjk

to make the behavior consistent across gdb versions, ignore the initial
*stopped which gdb7 delivers while attaching.

Reviewed-By: hjk

d'oh, of course, such frames *do* exist.

Reviewed-By: hjk

seems like gdb 6.8 isn't any better than 6.4 wrt file name
normalization.

Reviewed-By: hjk

i.e., don't allow user to confuse himself :)

technically, it would be cleaner to handle that in the adapters,
but it is a lot of duplicated code without any gain.

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