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>
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>
It's apparently still in use.
Change-Id: I89d04c6b3afff8014334e3543c3f3b77bf52d130
Task-number: QTCREATORBUG-19135
Reviewed-by: Christian Stenger <christian.stenger@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>
It's a lot more useful to see in Qt Creator:
QAbstractFileEngine::FlagsMask (0xff00000)
Than
QAbstractFileEngine::FlagsMask (267386880)
Change-Id: I8d96dea9955d4c749b99fffd14cd690574b433e5
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
To properly access a static member we need a nativeValue which we
don't have in the expansion of an array.
Not showing static members in that case is a compromise between
LLDB behavior (never show statics) and showing something wrong
(see the linked bug report)
Task-number: QTCREATORBUG-18366
Change-Id: I688779224a89d4ecbc47dd5623922efb32be9c4c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
It causes an exception when being divided
Noticed with boost::icl::interval_set.
Change-Id: I5629436c3c1ba10e7b67bb05d720329f4c61eafe
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This requires making template argument extraction a bit more robust
GCC 5.4.1 created debug info only reports the first argument for
boost::variant<int, bool>:
#include <boost/variant/variant.hpp
int main() { boost::variant<int, float> v = 1; return 0; }
py print(gdb.parse_and_eval('v').type)
-> boost::variant<int, float>
py print(gdb.parse_and_eval('v').type.template_argument(0))
-> int
py print(gdb.parse_and_eval('v').type.template_argument(1))
-> Traceback (most recent call last):
File \"<string>\", line 1, in <module>
RuntimeError: No argument 1 in template.
Error while executing Python code.
Change-Id: Iedca8b073078c93449ab61bb2cab05d6cd9803ba
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
These could be triggered by declared but undefined and unused
static data members.
Task-number: QTCREATORBUG-18030
Change-Id: I941e8cbe8ce18dca737e59472ed0ee19ace44072
Reviewed-by: David Schulz <david.schulz@qt.io>
Gcc does not write out full type names with 'using template ...', see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80466
This is in most cases harmless for Creator as dumpers are triggered
independently of template arguments. However, if the dumper takes
different code path based on the template argument type, as is
e.g. needed for std::vector<bool>, wrong results are produced,
as the type cache only used the template base name as type id.
Work around by mangling the id of the un-typedef-ed type into
the type id of a typedef, which, in case of templates contain
the full parameter list.
Change-Id: I63c59cccdc186b09ff780e9dfd57b0ad668ae98f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
We get proper notification when QtCore is loaded now, and we either
got it, or not.
Change-Id: I9485126d9b15b8d859ba440f3ba1623f03527ef8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Makes it clear that this is meant to be immutable and is supposedly
faster.
Task-number: QTCREATORBUG-17823
Change-Id: Ie5d67b793e0bc4f704981d5161efc12bcc22100a
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It worked with plain GDB (parse_and_eval), and was broken by
696b2d4261.
Change-Id: Ibc143efdbd90681a2f9f4d84b75063eb98078f2b
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Bail out on error results as early as possible.
The accessor always exists in libQt5Core, but it can't be found
when using a wrongly mangled name. Use the right one, and add
another sanity check before actually using the function.
Change-Id: I57975be188ca6b03836c0968e59d9603b0eecf27
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Needs to make namespace detection work without valid frame
Task-number: QTCREATORBUG-17326
Change-Id: Ia7c7017db4ef384d4f246e11a5601d01f4f366f1
Reviewed-by: hjk <hjk@qt.io>
... and use the option to govern general QObject guts display.
This allows people to completely avoid the performance impact
of attempted QObject display and still makes the feature
more prominent for our favorite use case.
Change-Id: I1e53b6448f646ab7eea9168a3cd24c77769e6328
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There have been cases observed where 'p QArrayData::shared_null' finds
valid symbols that are not found using gdb.lookup_symbols. The cause
for that is unknown.
Apply an expensive workaround by checking for (the equivalent of)
a working 'p QArrayData::shared_null' but execute it only when
a libQt5Core was found. This keeps the overhead for non-Qt setups
at a bearable (unsuccessful) iteration over known shared object
names.
Change-Id: Id398673b938d3c3a72c24317abdbefbe793e54df
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use Python's list and dict output directly, instead of
a manually stringified version thereof. Also, report
milliseconds instead of microseconds.
Change-Id: Ibcbdea732e7ecc58fd672bc5da794832215865b4
Reviewed-by: hjk <hjk@qt.io>
