This change resolves an issue where gdb.parse_and_eval could
rerun the multithreading application, causing breakpoints to be hit
repeatedly in different threads, leading to an infinite loop.
Added checkbox which enables skipping the execution of
gdb.parse_and_eval in few places that mitigate the issue.
Fixes: QTCREATORBUG-23219
Change-Id: I856d382d033f8a4da394d7422ebb3e131de28e09
Reviewed-by: hjk <hjk@qt.io>
It looks like there are Qt-using scenarios without easy way to have
the right Qt version in the kit,
Among the frequent cases where we need to distinguish Qt versions in
the dumpers are the Qt5/6 container layout differences which can in
some cases be detected from the currently dumped value. Use that now
as the primary distinction and fall back to the previous expensive
peeking only if that is needed. This also postpones any Qt version
related activity until a real Qt type is encountered, i.e. does not
impact non-Qt scenarios.
Task-number: QTCREATORBUG-31033
Change-Id: I67b6e34c42994ad9f6e8ec8698b430b55327cf0c
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Extend the solution from
commit d86cf5e235
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Sep 24 12:02:06 2020 +0200
Debugger: Retrieve and remember int from native GDB value
to also retrieve the int representation for numeric values
from the corresponding native gdb.Value if a typedef to
an integer or bool type is used, not only when an integer
type is used directly.
This makes expressions for bifield members in the
debugger's expression view show the correct value
when the type of those bitfield members is a typedef
to an integer type.
Extend the "Bitfields" dumper test accordingly.
One real world example where incorrect values were
previously shown is GtkWidgetPrivate from the
GTK library [1].
[1] ebc84a6185/gtk/gtkwidgetprivate.h (L39-76)
Change-Id: Ib39e00ebbfc8d7d9ab10dc89af61f37ec41fb4ee
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
The type cache has been split into smaller caches for individual
aspects. Type ids are now integral, not strings.
In addition, there is new supporting code for logging, timing and
profiling
Change-Id: I6db72a149650d42aecf8b899869c542b1303d43b
Reviewed-by: David Schulz <david.schulz@qt.io>
Reviewed-by: <github-actions-qt-creator@cristianadam.eu>
gobject_gdb.py puts the pretty_printer_lookup function into
gdb.pretty_printers. Trying to access subprinters of it causes the
AttributeError exception.
Change-Id: I00ce7b62866dd9c06a1f0abef0c7043ece023d34
Reviewed-by: hjk <hjk@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Task-number: QTBUG-67283
Change-Id: I708fd1f9f2b73d60f57cc3568646929117825813
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
COOKIE FOR TOKEN 0 ALREADY EATEN (InferiorStopOk). TWO RESPONSES FOR ONE
COMMAND?
Change-Id: I569a9715f073f3fbba71045f14fa30a06cd434e9
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Reviewed-by: hjk <hjk@qt.io>
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>
