...not only if the response id is known. Fixes stepping out with cdb..
Change-Id: I07dfc2b89703d5d0df80a30a658274529a68d18c
Reviewed-by: hjk <hjk@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>
This moves the thread switcher combobox, the only consumer
of part of the threadhandler interface, into the threadhandler.
Change-Id: Icafd72e7777fad9196ce8fb33a79cae26c29a521
Reviewed-by: Christian Stenger <christian.stenger@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>
- 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>
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>
This allows to run any command without knowing the current state of the
debugger engine. Replacing the old special stop mode for any command
that may be triggered while the engine is running, with a check in
runCommand. If the engine is running while a command is triggered a
callback is added to the interrupt that will execute the command as soon
as the engine is accessible again.
Change-Id: I8bb1914b92da2b03e76c2c2ec8293d13041c72fd
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The actual remaining use was to pop up a terminal in some
setups where Mode == Console, with a default of Gui meaning
"no console". In some downstream uses it was used set to
Console (probably to mean "this helper process does not need
a gui") but then luckily ignored when actually starting the
helper processes.
All cases where the console is useful and requested are
nowadays RunWorkers belonging to RunConfigurations with
a TerminalAspect, so they can directly get the relevant bit
from their RunConfiguration without having it part of
all StandardRunnables.
Change-Id: I1368d5968da5cf672656aebf200ccac8d45335d0
Reviewed-by: Christian Stenger <christian.stenger@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>
The symbol isn't safely resolvable and can lead to unwanted breaks.
Task-number: QTCREATORBUG-19628
Change-Id: Iaa58b12cb826a9e20faa64454e806ecab9d613f3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... into a EngineShutdownFinished. They were never handled differently,
and the only option is to proceed to DebuggerFinished anyway. So
simplify the state machine a bit.
Change-Id: Ied3be86fff6750abca578dc6788e4be1d895692b
Reviewed-by: David Schulz <david.schulz@qt.io>
It was needed in the past to trigger e.g. gdbserver setup in
remote cases which is nowadays handled by separate RunWorkers.
Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
The device is needed to properly interrupt the inferior with cdb.
Change-Id: I96f3a7393770be9821d8edd7123c458399d4494a
Task-nnumber: QTCREATORBUG-19253
Reviewed-by: hjk <hjk@qt.io>
It still fails with a soft assertion, but at least doesn't crash.
Task-number: QTCREATORBUG-19160
Change-Id: I3779f64e752abf9d3779219552a4a1be648f1dea
Reviewed-by: David Schulz <david.schulz@qt.io>
Do not add inferior command line arguments to the cdb process if we are
attaching to an already running process.
Task-number: QTCREATORBUG-19034
Change-Id: I7b9a98b790e819fc76ff4ec75769785741bfde83
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Moving the knowledge that this won't work well outside windows
kind of decreases encapsulation, but that's not really worth the
complication of the error handling here.
Change-Id: Idcb6f6d64f33ee8c49a01e62e20aad16d3f01b86
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... and apply even more force on the second trying by forcing
ramp down of the runControl itself instead of hoping that it
would pick up hints.
Change-Id: I9d0f4130cb9a137b91c9fa81c3d255f236f98be0
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Also, add context to connect() expressions where we are or were
capturing "this".
Change-Id: I6e006ba6f83d532478018550d148ee93eca59605
Reviewed-by: Tim Jenssen <tim.jenssen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Tell QTestLib to use OutputDebugString for logging when "Run in
Terminal" is turned off. This way we are able to distinguish CDB's
output from the debuggee's output.
Task-number: QTCREATORBUG-16161
Change-Id: Ie5e6e4a0cbb853167766f782521101eff2e1963a
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The device is always available via runTool().
Change-Id: I4a2a791a5a75b32803c06fc34947b82b869fe31c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There were only two used target states, and in case of mixed
debugging all parts of the machinery better agree on the
direction. So one bool in the (shared) runTool is sufficient.
Change-Id: Iffbf1651b82dde707cfc37d8da9d3da573b34b76
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The parameters belong to the run control, they should not
be triplicated in case of a combined engine.
Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
