The breakpoints are now (fairly) tightly guarded by the BreakpointHandler.
Engines and Views are only supposed to refer to them by id. They also have
individual states now. The breakpoint data is split into a "user requested"
"fixed" part in BreakpointData and the engines' acknowledged data in a new
struct BreakpointResponse.
TODO: Move m_state and m_engine members to BreakpointResponse. Fix regressions
in the marker handling.
Check whether the ports we need are actually available on the device.
As a side effect, this makes it possible to debug more than one
application at the same time on Maemo.
Task-number: QTCREATORBUG-2702
assignValueInDebugger: Pass on WatchData as well, pass
on values as QVariant. Based on that, do more extensive
checks in CDB, preventing assignment of non-PODs.
Locals/Watch editing:
* Disable while running
* Edit pointer values as hex with validation.
CDB: Strip class types off reported pointer values and reformat
the values as short 0x-pointer values, introduce flag to
WatchData::source to do dumper expansion handling.
Windows: recognize int64 as int.
Register handler: Fix accessing uninitialized value.
Without doing some magic for the filenames, we go to shadow build files
instead of the real ones, resulting in confusion. The user should never
see the shadow build files while debugging.
Reviewed-by: hjk
A new debugger engine, QmlCppEngine, is introduced, which wraps gdb
and qml engines into one. Alternatively, if using Windows, Cdb is used
instead of Gdb.
Most of the debugger ui switcher is now rewritten, and it is tailored
for the QML and CPP layout case, the only one supported anyway.
Reviewed-by: hjk
Now, QmlEngine creates the connection to the inferior (debuggee), and
notifies QmlInspector when a connection is established. Before,
inspector created the debugger engin, which was wrong.
QmlEngine's responsibilities are connecting to the debuggee and basic
QML/JS debugging features like locals & watchers, breakpoints etc.
QmlInspector takes care of Live Preview and other fancy inspection
features.
Reviewed-by: hjk
A copy of the client debugging code is made in src/libs/qmljsdebugclient/
(this comes from the qt code from commit 65642dd343bf61)
So the qmljsinspector plugin does not require anymore Qt private headers.
This replaces the (de facto) singleton engines and data handlers by classes
that are instantiated per run. The DebuggerRunControl will now create an
object of (a class derived from) DebuggerEngine that contains all the relevant
"dynamic" data.
DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
whereas the data bits went to DebuggerEngine.
There is no formal notion of a "current" DebuggerEngine. However, as there's
only one DebuggerEngine at a time that has its data models connected to the
view, there's still some "de facto" notion of a "current" engine. Calling
SomeModel::setData(int role, QVariant data) with custom role is used as the
primary dispatch mechanism from the views to the "current" data models
(and the engine, as all data models know their engine).
