The dumper calls PyObject_Repr and shows the result of that as the
value of a PyObject.
It also adds three new sub fields to show the object class (type),
super class (base class), and the meta type (the type of the class
object).
Change-Id: I0612833321f6d2b50826588e775cfa12e1db28e4
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: hjk <hjk@qt.io>
This is achieved by calling "po" on an address value casted to a
simple function pointer type, regardless of the actual type of
the function pointer. lldb does not complain, and reports the
library where the function is defined, its name, and location
in the source code if available.
Change-Id: I23ccce62e33bcf213ccdcb55c9836d54333f3c86
Reviewed-by: hjk <hjk@qt.io>
Needs some hint that floats are involved.
Change-Id: Ie6871ce3b6bb7aaff27e6c763a6002a6d0a90d70
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
On Linux. Required installs are the gcc-built Qt libraries themselves,
the "Sources" and "Qt Debug Information Files" components.
Fixes: QTCREATORBUG-20693
Change-Id: I920efd641ce3ee4583741ea1db0bea18031adc51
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Mostly for sanity reasons when debugging the QObject dumper itself.
Change-Id: I7d6267625f091788e73b0b28695e9b99e33ab3e3
Reviewed-by: David Schulz <david.schulz@qt.io>
The 'putSubItem' method expects an object of the
Value class as defined in 'dumper.py'.
Therefore, create such an object for the gdb.Value
when passing it into the method.
Task-number: QTCREATORBUG-21000
Change-Id: I5277f832ee2aae808824f3dcf728fdaa0e2a3c78
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Use the name attribute of the gdb.Type rather
than that of the pretty printer.
This e.g. displays 'std::vector<int>' rather than
just 'std::vector' for an int vector.
Change-Id: I53da01bb5ba67bcd8d7113beda6ff03e708d60f9
Reviewed-by: hjk <hjk@qt.io>
It has an internal QWeakPointer<QObject>, which is not helpful. Cast to the
QPointer's template argument instead.
Change-Id: I9308c5eb9ea3867a682c4e4cba5d8041547981d1
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
When used in SubItem, enums were displayed as
"value of type E at address <addr>".
Change-Id: Ieecfb791126c6f63f272817afc6c8d05f28b9242
Reviewed-by: David Schulz <david.schulz@qt.io>
Qt Creator failed to properly display GDB's LazyString.
The problem was that GDB's 'PlainDumper::__call__' passed a 'gdb.Type',
while 'DumperBase::putCharArrayHelper' called methods that are only
defined for the custom and more abstract 'Type' type defined in 'dumper.py'.
As described at [1], GDB's 'LazyString.type' "holds the type that is
represented by the lazy string’s type. For a lazy string this is a pointer
or array type. To resolve this to the lazy string’s character type,
use the type’s target method."
In addition, 'gdb.Type' does not have a 'size()' method, just a 'sizeof'
member, s. [2].
Since all other uses of 'DumperBase::putCharArrayHelper' are passed
a "proper" type, extract the code common to the GDB case and all others
into a separate method and directly call this one for the GDB LazyString
case.
[1] https://sourceware.org/gdb/onlinedocs/gdb/Lazy-Strings-In-Python.html#Lazy-Strings-In-Python
[2] https://sourceware.org/gdb/onlinedocs/gdb/Types-In-Python.html#Types-In-Python
Task-number: QTCREATORBUG-20939
Change-Id: I16608668c9403b6d8e509dab17eb1788586f453e
Reviewed-by: hjk <hjk@qt.io>
Judging from the code it either never worked, or LLDB changed
syntax at some time. In either case, having it in a usable
state with current version is an improvement.
Change-Id: I88b15969bf28b92735d860544dedcbd1d9689765
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
No real damage, the parser on the Creator side is apparently robust
enough. Still no need to add this.
Change-Id: I8329a55c44f866070fb3df48c3a22000ee33e848
Reviewed-by: David Schulz <david.schulz@qt.io>
Make the hex display work with LLDB, fix GDB and LLDB test.
Change-Id: I529b5cdc908dbcba7270bc4574fa59a012fcacad
Reviewed-by: David Schulz <david.schulz@qt.io>
Linux/gdb only, pretty print the cases of default constructed objects
and real function pointers.
Task-number: QTCREATORBUG-19410
Change-Id: I08332af649bda861d9f53c0e0feb1f37db72b875
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Replace Evaluate with AddSymbol and create a PyValue representing
that expression
Change-Id: Ibb8ab70c41df81e9d7d683b633a070caa03036d3
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>
This function is available only for GDB. When using CDB or LLDB
this ends up in an exception.
Change-Id: Ie1835c1b95cac99e3f996077f6a3d80b5591c145
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The lookup is quite slow, and will hang the lldb debugger,
causing Xcode to hang too.
Change-Id: Ic6579a5de9404c0040d3d304169f18109f61d2ac
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It's apparently still in use.
Change-Id: I89d04c6b3afff8014334e3543c3f3b77bf52d130
Task-number: QTCREATORBUG-19135
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For some reason sometimes a user stop request with lldb can trigger
a spontaneous stop, avoiding the debugger to stop correctly.
This change fix the issue by emitting the correct states from
lldbbridge.py.
Change-Id: Ib8a2f4875824f4fff426b2d5e0fc4a79ce48c68e
Reviewed-by: hjk <hjk@qt.io>
