Too much cleverness in python command detection: "attach" is parsed
as possible Python command. Make it explicit that it is not.
Task-number: QTCREATORBUG-21908
Change-Id: I68444bccfb485ef1befe81b4b6b13243c2c8a500
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
When the breakpoint is put on a non-code line, it will be moved to the next
line that has debuggable code on it. When attempting to reset the
breakpoint to the originally requested line, this causes an infinite loop
of removing and re-adding the breakpoint.
Fixes: QTCREATORBUG-21611
Fixes: QTCREATORBUG-21616
Change-Id: I8943de0eae991644eb6728f491010599f62192ff
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
... for temporary stops.
The transition is not unexpected, we just failed to communicate the
expectation.
Change-Id: I30cdcffdcc3672e759023cd0c07de4bea11c2e32
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Main menu action pass operation to current engine, everything else
is handled there.
Combine execute{Step,Next} and execute{Step,Next}I functions.
Implementation were mostly similar, in some cases unneeded
(the instruction-wise version e.g. for Python)
Drop GDB-isms 'step', 'next' in favor of 'step in' and 'step over'.
Change-Id: I232232bc7a67d9d297a74f1c81dc43be96787d34
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
GDB doesn't provide thread-core on core dump debugging.
Give the user the option provide it.
Change-Id: I15eae0280243ce307b9045be33e4b28e9b9c64d0
Reviewed-by: hjk <hjk@qt.io>
Do not try to read locals and threads when hitting a breakpoint with
"continue" command, as it doesn't really stop.
Change-Id: I2adc02d9f94375c390a874122afe2a82a764dc64
Reviewed-by: hjk <hjk@qt.io>
(and keep updateThread() for the single-thread case)
All backends create full lists, making that explicit allows to
simplify the interface.
Change-Id: I717cfcf3ec9f8e81df8a5dfc71ae84855bc3beae
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Explicit polling is still available and accessible as fall back in
the gui, but is at least in theory not necessary anymore.
Change-Id: Ifd184fb88bdbf5de53f5776e2c94a03f8ad44a06
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
- Use the TreeItem/data pattern recently introduced with Breakpoints
to remove the need of keeping track of id/object mapping. Opens
possibility to have thread groups as intermediate level.
- Use the ThreadHandler directly as model for the thread combobox
to remove the need of manual combo box updates.
- Move setting current thread from individual engines to central code.
Change-Id: I030e21a4aa5ab30b0efbc84528d9cecf29cbbe30
Reviewed-by: David Schulz <david.schulz@qt.io>
Combine two branches. The function is only used in the remote and the
local plain case, and the resulting actions were the same.
Change-Id: I30c0b4488f04667d88b69f2c8ecd1dead92e0766
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
This is a step towards properly supporting multiple debugger
sessions side-by-side.
The combined C++-and-QML engine has been removed, instead a
combined setup creates now two individual engines, under a single
DebuggerRunTool but mostly independent with no combined state
machine. This requires a few more clicks in some cases, but
makes it easier to direct e.g. interrupt requests to the
interesting engine.
Care has been taken to not change the UX of the single debugger
session use case if possible. The fat debug button operates
as-before in that case, i.e. switches to Interrupt if the
single active runconfiguration runs in the debugger etc.
Most views are made per-engine, running an engine creates
a new Perspective, which is destroyed when the run control dies.
The snapshot view remains global and becomes primary source
of information on a "current engine" that receives all menu
and otherwise global input.
There is a new global "Breakpoint Preset" view containing
all "static" breakpoint data. When an engine starts up it
"claims" breakpoint it believes it can handle, but operates
on a copy of the static data. The markers of the static
version are suppressed as long as an engine controls a
breakpoint (that inclusive all resolved locations), but are
re-instatet once the engine quits.
The old Breakpoint class that already contained this split
per-instance was split into a new Breakpoint and a
GlobalBreakpoint class, with a per-engine model for Breakpoints,
and a singleton model containing GlobalBreakpoints.
There is a new CppDebuggerEngine intermediate level serving as
base for C++ (or, rather, "compiled") binary debugging, i.e.
{Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine
base that are not applicable to non-binary debuggers.
Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The commands are wrapped in quotes, and if they contain quotes it gets
messed up.
Change-Id: I41cebd8cf4a57a8ea671e5f43a3295af1c73fd02
Reviewed-by: hjk <hjk@qt.io>
Passing an empty string to QFile::exists() results in
'Empty filename passed to function' to be printed on the
commandline.
Change-Id: I028f0ec18447642b30be1a51f4c70b6ae18d45b1
Reviewed-by: hjk <hjk@qt.io>
There's no actual change, the code could only be triggered when
the gdb side was active, but it triggered a stop of the combo
which then redirected to the active one.
It's always and only the gdb side that needs stopping, so do
it directly.
Change-Id: I1a6273b826be8f38993c9968d874b7b3daf0d0c7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As all Runnables are known to be StandardRunnables, this here
essentially replaces all .is<StandardRunnable> by 'true'.
.as<StandardRunnable> by no-op, and fixes the fallout.
Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
There's seems to be the possibility to actually trigger the assert
this patch removes with MinGW and mixed debugging.
While the reason for that is not clear yet, there's no need to
force the debugger to abort. The observer wrong state was InferiorRunOk,
so just continuing on the selected path will do the right thing
(i.e. attempt to interrupt the debugged process)
Change-Id: I534cedd71522e73d5f1097ddd472efbeb3b4d97f
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This was useful to trigger collective attemptBreakpointSync() in the gdb
engine when gdb did not yet track pending breakpoints by itself.
That's not needed anymore.
Change-Id: I8afd2955070504c6bd6ae6c028b3f006b6eb4d7c
Reviewed-by: David Schulz <david.schulz@qt.io>
This does not involve the engine (currently).
Task-number: QTCREATORBUG-19994
Change-Id: I07a628580bf99c988eb0df165d649d5cc0869c0d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Mostly nullptr instead of 0, but also a few bits of collateral damage.
Change-Id: I921991272aca921dcdecf302dfff3716e79dfc24
Reviewed-by: David Schulz <david.schulz@qt.io>
... for breakpoints that resolve to multiple locations, like templates.
Toggling is done via the the breakpoint view context menu, for now
only available with GDB and not persistent.
Change-Id: I098ae13a5518e9f671c647680f8bd4413e7e5ccc
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
