GDB 8.1 changed behavior when specifying breakpoints, it now tries
to pattern-match function names, hitting e.g. 'Foo::abort()' for
'b ::abort'.
While the API exposes a way to opt-out of the new behavior there's
no way to tell when to do that other than trial-and-error.
Task-number: QTBUG-73993
Change-Id: Ied2e640e65e40df6eac50117db890bd4b51d36ab
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There have been apparently changes on the Qt Declarative side.
Task-number: QTCREATORBUG-22209
Change-Id: Ia9e387aa92465556b5b8aee3661e2fc063478f3d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Hexencode the output from GDB pretty printer, since
Double quotes ('"') and potentially more characters
need to be escaped in order for the variable values
to be properly displayed in the variable pane while
debugging.
The 'utf8:1:0' parameter to 'putValue' (as compared
to just 'utf8') makes sure that no extra quotes are
displayed at the beginning and end of the value.
Fixes: QTCREATORBUG-22135
Change-Id: I4ad9fdc75d8f389cc4cdd18d5da1eec242f8a329
Reviewed-by: hjk <hjk@qt.io>
Amends f75a7fa036: Not every gdb knows TYPE_CODE_RVALUE_REF, in that
case we ended up with no locals displayed.
Change-Id: I4dab1b18cdd46abf1a3a54a237f1cd314ac50feb
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Prioritize displaying as enum if a type is known
to be an enum. Otherwise this would just end up
get displayed as string representation of its value.
Enable respective dumper tests.
Change-Id: I3e5406e14a68f02741b6144bb54528b72cc8192d
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
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>
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>
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>
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>
