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>
If people already decide to drill into QString they are likely
to want to be able to drill into QString::Data, too.
Change-Id: I90cf1bd9b7bed66805fc7493cf1595d27ef3b129
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: hjk <hjk@qt.io>
... as well as std::vector and QVector
Change-Id: I7fd33be9917a17414149813c28316166b8de9be7
Task-number: QTCREATORBUG-18681
Reviewed-by: André Hartmann <aha_1980@gmx.de>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
