Move common code to dumper.py and debuggerengine.cpp and
fix it there.
Change-Id: I20d91d1aa7400fbdb27938c10cf40c8f6019df0a
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Recent regression, stack data was only pulled when hitting
a breakpoint, not on interrupt.
Change-Id: I3de29fceadd4c5492f4edaffca7577dae7ae3d11
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
... in WatchHandler and DebuggerEngine interface.
Adjust using code.
Change-Id: I6371f3e96ba46a783e23a5767cdde24a10d3fce7
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
... and further unify GDB and LLDB code paths.
Change-Id: Id89f3804c53190c4888082891fd3c3c55eceac84
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
The only information ever used is whether it's c++ or not.
Change-Id: I4ca00663856dd66cbdf58c468f175a8c9e41d6a5
Reviewed-by: hjk <hjk@theqtcompany.com>
Only needed in the non-Python days. CDB didn't use it to start with.
Change-Id: Ia609218cc1a694f797e278c4d99ead68e6212938
Reviewed-by: hjk <hjk@theqtcompany.com>
This also removes some of the "illegal" state transitions,
partially addressing QTCREATORBUG-14089.
Change-Id: I817d87a0b5e0a40285bc9b0880fef5bceaee3f16
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
This also addresses the remaining issues of QTCREATORBUG-13803.
Task-number: QTCREATORBUG-13803
Change-Id: Iceb123279236d98961d15fe7421acc7c10d1b1c7
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Ideally, all 'current' data should be passed down from the engine.
Change-Id: Ibfe7c466ec564c6907398ec2ec6c05d04e6670d6
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
The stack might produce data (such as as the QML context in
native mixed debugging) that is needed for locals display.
While this doesn't work yet with LLDB anyway, the change
suppresses one soft access when accessing the top frame of
an empty stack (the usual case on the first update).
Change-Id: If931fbe940b8cda01cc6cc34429a2fcb33cd8d19
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Breakpoints inserted before application start are not
just 'InsertRequested' but already 'InsertProceeding'.
Change-Id: I1df37d15f74ea65771843f6eab2e724d2bb0cd23
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
Change-Id: I91979c685bbbd84359f7f4e19911a21a408f5d23
Reviewed-by: hjk <hjk@theqtcompany.com>
Move reusable Breakpoint enum to base, use 'theDumper' uniformly
across backends as name for the Dumper singleton. Signal
engine setup only if the Dumper successfully initializes.
Change-Id: If1b6be9d054f249d0d46061e4949cbecf4fd09cb
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Instead of calling a GDB extension command invoking a function
on the well-known Dumper instance, call the Dumper function
directly. This also makes the code more similar to the LLDB side.
Change-Id: I4b23177eb72a904721b63c578ce7fbfe204f02a2
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Less stylish options for more uniform user code.
Change-Id: Ie9a6558101383a844efa25ba3ab59b4b824ad89f
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Breakpoints are hit, stack frames are identified as JS or native.
No further data yet.
Change-Id: I84a02422fd36dc7645003114dd8519bedd913c06
Reviewed-by: hjk <hjk@theqtcompany.com>
Instead of starting LLDB through a Python script this now starts
LLDB directly. This did not work a while ago but seems fine nowaday.
Change-Id: I20e915070cd6addf260817c311f4160d010aa861
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>
This generalizes part of the previously GDB-only code paths
Change-Id: Id32798073e3c8bcb23bfedf463bebc866c8275e2
Reviewed-by: hjk <hjk@theqtcompany.com>
The actual data is now in a TreeModel. As interface to
individual breakpoints there's a new Breakpoint class
essentially providing a checked handle.
On the user code side breakHandler()->foo(bpId) is
replaced by bp.foo().
Change-Id: I82f435bad6301fce85a1d82bf6bf39e9ddba511e
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Use register names as handle, not their index in the view.
Store the raw real values, not some stringified version
as primary data. Use subentries to break down bigger
registers into smaller entities. Also remember the
previous value of a register and show it in a tooltip.
Change-Id: I8ae3cc8766a7b211bc7cc827c734e5cf6060825c
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
Nested event loops can lead to crashes, so it is better to use a dialog
which does not have have its own event loop.
Change-Id: Icd2390c9026bc1ef88e72a570df5813fe5cbdaa2
Reviewed-by: hjk <hjk121@nokiamail.com>
Pending breakpoints have zero resolved locations.
Change-Id: I18cecfabe8dcfebb7733030a404f75603464d157
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Unneeded effort and also re-sets the marker to the top frame
somewhat spoiling part of the result.
Change-Id: Iebaa52dc8c0703f3245cac2ca15b942e3006993a
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
