Rename internally used classes and suppress them
explicitly while debugging python code to not display
them on the Locals and Expressions.
Change-Id: Ia396243172b2d138c9f4c81b2f1ed0fec0dce3d3
Reviewed-by: hjk <hjk@qt.io>
When parsing the file path of location information the
GdbMi parser expects UNIX-style formatted paths.
When debugging with the pdb on Windows we reported
Windows-style paths which in turn made the parser fail
and the stack never contained a file name and the
current location also had never a marker displayed.
Change-Id: I5216bbaf39ceead63efe8426561f132de3cd04a2
Reviewed-by: hjk <hjk@qt.io>
Makes it possible to access the entry lists if these were populated by
the code.
Change-Id: I066824d2ce7f75a38d208155156c93d06458f8b3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The iterator type is std::_Rb_tree_iterator<std::pair<K, V>>
Change-Id: I0ed2f2e6955deb4b402277fe0f3eb32b6af2d477
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The code path for allocators other than
'std::allocator' does work for 'std::allocator' as well,
so unify this.
This also fixes the case of std containers when
'std::allocator' is used and the compiler flag
'-D_GLIBCXX_DEBUG' in place which results in size assumptions
that were made in the now dropped path to not be fulfilled,
thus leading to an incorrect display.
Fixes: QTCREATORBUG-22606
Change-Id: I2b6f8ac9933b210d26197975017292e2fc227541
Reviewed-by: hjk <hjk@qt.io>
This fixes expansion of 'std::basic_string' in the locals
view when a custom allocator is used (which previously
would result in "<not accessible>" being shown);
for example, when expanding 's' at the breakpoint
in the following example:
#include <string>
template<class T>
class myallocator : public std::allocator<T> {};
int main()
{
std::basic_string<char, std::char_traits<char>, myallocator<char>> s("hello");
return 0; // break here and expand value of 's' in locals view
}
Change-Id: I0ca98de50d83a1f6e6f019acc37a1302a05fdba8
Reviewed-by: hjk <hjk@qt.io>
This fixes the std::vector<bool> pretty printer, which
previously just showed "<not accessible>" for variable
'v' for the following sample code (with system GDB
pretty printer disabled so that the custom
pretty printers are used):
#include <vector>
template<class T>
class myallocator : public std::allocator<T> {
};
int main()
{
std::vector<bool, myallocator<bool>> v;
v.push_back(true);
return 0; // break here and check value of 'v'
}
Change-Id: Ia9883aa0b06a396cb3546ac2594a82c1b2062b80
Reviewed-by: hjk <hjk@qt.io>
'Dumper::fromNativeValue' expects an object of type
'gdb.Value'. However, the 'pretty_printer.children()' iterator
may return values that first need to be converted to this,
as documented for function 'pretty_printer.children' at [1]:
> This method must return an object conforming to the Python iterator
> protocol. Each item returned by the iterator must be a tuple holding two
> elements. The first element is the “name” of the child; the second
> element is the child’s value. The value can be any Python object which
> is convertible to a GDB value.
Therefore, explicitly convert the value to a GDB value first.
This fixes the expansion of 'std::vector<bool>' when system
GDB pretty printers are enabled which previously led to
"<not accessible>" being shown e.g. for the following example
(expand 'v' in the local variable view at the breakpoint):
#include <vector>
int main()
{
std::vector<bool> v;
v.push_back(true);
return 0; // insert breakpoint here
}
Side note: GCC's pretty printer for 'std::vector<bool>' previously
returned either '0' or '1' for the element values, thus leading to the
problem described above. With this patch in place, the elements are
shown when the vector is expanded, but the shown type is 'long long'
(since that's the type that GDB seems to automatically assign when
constructing a 'gdb.Value' from these integers, at least with
GDB 8.2.1 on amd64). This will work as expected ('bool' shown as
type) from GCC commit [2] on ("Have std::vector printer's iterator
return bool for vector<bool>").
[1] https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
[2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=6c7d761a3f5fd7d19795d1d4b9b027a04b3fe88b
Change-Id: I9047affa5b4369befd2e2386c8a6b04c66c4b632
Reviewed-by: hjk <hjk@qt.io>
Don't use two lookups for parent types and act on known null pointers.
While the machinery is robust enough to handle the result it's a
needless deviation in regular code path.
Change-Id: I6e50629cf554870a3ffb9f488f654e6ae557e5b3
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
... when non-std allocator is used.
This patch is a follow-up of 41da97fb2c.
Task-number: QTCREATORBUG-22040
Change-Id: Ib3e7699ccb77fd2c934d28367629d78dbf5379d8
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
... that were not updated when the structures changed.
Change-Id: I1c06ac029f2057d618ce21b5da3edf9694cff63d
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
As per suggestion from Pyls, this changes
if not needle in haystack:
to
if needle not in haystack:
Change-Id: I4a482604e13e61ecee9e02935479632419710ff7
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
Should help to drill down to individual expensive dumpers.
Change-Id: I983ba075231784f71dd9d5c3bda375a3ee508bf6
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
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>
This is a workaround for excess messages from the early LLDB 3.x times.
LLDB 6.0 is ok with and without this workaround, LLDB 7.0 does not
produce the excess messages anymore and the workaround leads to
real stop messages e.g. after a breakpoint hit being ignores.
Change-Id: I2fad014eb92e066b00dbfe590fe62c543e5343f4
Task-number: QTCREATORBUG-21615
Reviewed-by: Christian Stenger <christian.stenger@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>
There's no need to go through unknown enum sizes here, they are known.
Also, make it work for namespaced Qt. Avoid casts to typedefs.
Change-Id: I9c6fc44a03a0c245f05957306a129f6902f8cf85
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
