Previously, if enabled in the configuration, system
GDB pretty printers were loaded only once for all
objfiles present at the point in time when the loading
happened, which meant that GDB pretty printers for
objfiles loaded later were not taken into account
and thus unavailable if they were defined in the
corresponding autoload scripts for the objfiles.
In order to make use of those as well, remember whether
loading of system GDB pretty printer is enabled, and if so,
evaluate the pretty printers set at the new objfiles
in the handler for GDB's new_objfile event.
Extract the functionality for handling one objfile's
pretty_printers to a separate function
'importPlainDumpersForObj' to avoid code duplication.
Note: For this to actually work, it is required that the
objfile passed to the registered GDB new_objfile handler
actually has the pretty printers set at this stage.
This was only recently implemented on GDB side, in
GDB commit 2c473def12b08100e6b56261f01112db7f6aeab5
("gdb: do autoload before notifying Python side in
new_objfile event", 2021-04-27, [1]).
Therefore, this currently only works with the current
development version of GDB built from its git master
branch, not with any already released GDB versions.
(When older GDB versions are used, this will just behave
as it used to, and the corresponding GDB pretty-printers
will not be used.)
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=2c473def12b08100e6b56261f01112db7f6aeab5
Fixes: QTCREATORBUG-25339
Change-Id: Ibc0ab16fbb75184fa199c0709bfc73954f04c193
Reviewed-by: hjk <hjk@qt.io>
Since GDB commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a [1]
("gdb: Enable stdin on exception in execute_gdb_command",
committed 2020-01-24), stdin for GDB is re-enabled whenever
an exception is caught during 'gdb.execute()'.
When running the dumper tests for GDB, such an exception
was thrown when loading the qtcore library, resulting
in the GDB commands after the 'run' command (s.
'tst_Dumpers::dumper') to be be handled by GDB prematurely
when loading the library instead of when reaching the
end of the test program.
This resulted in the dumper tests failing with output like
29: (gdb)
29: &"up 0\n"
29: &"No stack.\n"
29: ^error,msg="No stack."
29: (gdb)
29: &"python theDumper.fetchVariables({'token':2,'fancy':1,'forcens':1,'autoderef':1,'dyntype':1,'passexceptions':1,'testing':1,'qobjectnames':1,'expanded':['local']})\n"
29: &"Traceback (most recent call last):\n"
29: &" File \"<string>\", line 1, in <module>\n"
29: &" File \".../qt-creator/share/qtcreator/debugger/gdbbridge.py\", line 711, in fetchVariables\n"
29: &" variables = self.listLocals(partialName)\n"
29: &" File \".../qt-creator/share/qtcreator/debugger/gdbbridge.py\", line 597, in listLocals\n"
29: &" frame = gdb.selected_frame()\n"
29: &"gdb.error: No frame is currently selected.\n"
29: &"Error while executing Python code.\n"
29: ^error,msg="Error while executing Python code."
Avoid the exception by first trying to 'gdb.execute' the
command that works for GDB 8+ and fall back to the command
for earlier GDB versions, i.e. reverse the order. That
should be fine for all GDB versions, given the commit
mentioned above is only contained from GDB 10 on.
While at it, move the assignment to 'cmd' into the
corresponding 'try' blocks to make the context a bit
clearer.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=1ba1ac88011703abcd0271e4f5d00927dc69a09a
Change-Id: I2d1bb52a777801e6bd77a5eda581a2fd5dd3a18f
Reviewed-by: hjk <hjk@qt.io>
When adding expressions for bitfield members in the
debugger's expression view, their corresponding 'gdb.Value'
does not expose the fact that those are actually bitfields,
so e.g. an 'int : 3' is exposed like a "normal" 'int'.
Previously, this would result in wrong values being
retrieved in the 'DumperBase::Value::integer()' function,
when trying to read the value from the corresponding
memory address.
To avoid this, retrieve the actual int representation
for numeric values from the corresponding native 'gdb.Value',
remember them and return that one, similar to how it
is already done for known bitfield members
(s. 'Dumper::memberFromNativeFieldAndValue').
The conversion from the 'gdb.Value' does not work
for integers of a size larger than 64 bits
(like '__int128' used in the "Int128" dumper test).
Therefore, just ignore conversion failures and don't
remember any value explicitly for those cases,
so the same handling as previously used is applied.
(At a quick glance, the reason seems to be that this
is because GDB's corresponding functions use 'int64'
as a return value of the relevant functions [1] [2],
but I did not look closer into what GDB does
internally.)
Corresponding tests will be added in a separate commit.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-types.h;h=f5b2f3d249177acea77231c21c5601f959c18d2f;hb=f3034e25fa98d44b775970f40c9ec85eeae096e6#l33
[2] https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/python/py-value.c;h=6e29284aad11ff344789152a4f601b3474d86bb5;hb=f3034e25fa98d44b775970f40c9ec85eeae096e6#l1706
Fixes: QTCREATORBUG-24693
Change-Id: Idfc3390115e8796f3c778070c23424c3dbdfeddd
Reviewed-by: hjk <hjk@qt.io>
Enable the functionality for cdb again.
Change-Id: I75405f830dd208cc110d6682a45beedf2f4199cc
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: hjk <hjk@qt.io>
The intention was to always show errors, as this is likely an error
in the dumpers themselves. The case of operating on uninitialized
data is rather rare in the manual use case here.
Change-Id: I08874e302b402be94f760f744e82e127855dd16f
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Gdb from MinGW 7.3.0 and 5.3.0 crashes on Windows when we try to
evaluate expressions that result in a function call. At least prevent
evaluating such expressions from within the dumper.
Task-number: QTCREATORBUG-23477
Change-Id: Ic14148a43b95aa1b52c1d4488958fa66eccdc0b5
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
generated with autopep8 and the introduced setup.cfg
Change-Id: I5b55a7937f2cde81be59d2b434e94ada1a4af5ab
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Using imports like
from foo import *
is considered as bad habit and it reduces
static code analysis usability.
Change-Id: I56a175f4c7b231e2b8e486bd9d1c65543720f56a
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The documentation for the GDB pretty printer function
'pretty_printer.to_string' says [1]:
> [...]
> Finally, if this method returns None then no further
> operations are peformed in this method and nothing is printed.
> [...]
Therefore, skip this part if the printer's 'to_string' method returns
'None' and only fall back to assuming LazyString otherwise.
This e.g. fixes the std::pair pretty printer (for gcc-9 libstdc++6) for
which "<not accessible>" was shown previously in the debugger's
locals/expression view. Now it shows the object's address and allows
expansion to see the values for the 'first' and 'second' members.
[1] https://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
Change-Id: I33b1af82f731c347314af76c533b096b8a5afe21
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Looks like there is no attempt made on the GDB/libstdc++ side
to recognize uninitialized objects, so we cannot convert
"all 932 million children, I swear" to a list.
Task-number: QTCREATORBUG-22887
Change-Id: I3bf7e53c8b11ece3e1182d8446e959a66a41665a
Reviewed-by: Christian Stenger <christian.stenger@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>
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>
