And don't show the plain members anymore, unless explicitly asked.
Change-Id: I9854276c380d417fb9a98ae9c0dbae9356d42086
Done-with: Thiago Macieira
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
It is the result of the previously attempted SBPlatform.ConnectRemote()
which we want to see in the logs if the connection fails.
Change-Id: Iec2760257eb8bb8c6b1df8aa3a5c010302966c8f
Reviewed-by: hjk <hjk@qt.io>
Make more stdint, quint and char types known to the debugger.
Task-number: QTCREATORBUG-26501
Change-Id: I1e757af2a495142fa37fe2b7cefec56690adbf08
Reviewed-by: hjk <hjk@qt.io>
* Make (u)intX_t known as integral type
* Handle uint8_t[] the same way as char[] and unsigned char[]
Task-number: QTCREATORBUG-26501
Change-Id: I1eac21be198f8107f088e56daf435b5bb3217120
Reviewed-by: hjk <hjk@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>
Before this change I was seeing all strings as
`<failed to decode '...' as 'utf16'>` when using LLDB bundled with CLion.
This error is misleading since the actual exception raised from the python
code was `'str' object has no attribute 'decode'`. To fix this, I updated
the hexdecode() method on Dumper to accept an optional encoding argument
and use that instead of the python2 str.decode().
Change-Id: Ic3afc786c42fd7384d9dc3117f0871837076c2ba
Reviewed-by: hjk <hjk@qt.io>
..if loading the qml stack failed, e.g. when using a Qt
without debug information.
Task-number: QTCREATORBUG-25554
Change-Id: Ibe2a051f4dc0a9d3c15a63f663f5934a476d6fc4
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>
Although already tried to lookup a native type with an
lldb internal mechanism we still tried to do it "manually"
again.
This secondary approach was needed at some point when lldb
had no integrated way to lookup a type inside all modules.
Lookups done manually will not provide a better result than
the lldb internal one.
The error output generated with this blocks debugging which
makes QC unusable at this state.
So, remove the secondary lookup completely.
Fixes: QTCREATORBUG-25185
Fixes: QTCREATORBUG-25217
Change-Id: Ibd8a125a89633c611bf750e0f1759c639717e1d2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Previously, the starting inferior was sent a SIGSTOP to avoid
progress before the debugger could attach.
However, these signals are then also visible in the debugger and
need to be ignored as part of the startup handling in Creator.
The waiting effect can be achieved less intrusively by waiting
on a pipe read between fork() and exec().
Task-number: QTCREATORBUG-25073
Task-number: QTCREATORBUG-25082
Task-number: QTCREATORBUG-25227
Change-Id: Ie70b9eb5ea865f85411c26b0dbf377a019fec8d5
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
If automatic dereferencing of pointers is enabled, the
"Value" and "Type" columns for pointers hold the values for
the dereferenced pointers.
In order to have a consistent behavior for the "Name" column
as well, prepend '*'s to indicate that the variable/expression
has actually been dereferenced.
Add parantheses around the original expression if it doesn't
match a simple regex for variable names, to avoid that the
leading '*' changes the meaning of the expression
(so e.g. a dereferenced 'somepointer + 1' is displayed
as '*(somepointer + 1)' rather than '*somepointer + 1').
This introduces a new 'autoderefcount' field to propagate the
information how many levels of dereferencing have taken
place from the Python to the C++ side, which is then
used to add the leading '*'s for the display name.
Fixes: QTCREATORBUG-20907
Change-Id: Ia9a41cb42e25ba72a6d980a765dbe2b454deb8c8
Reviewed-by: hjk <hjk@qt.io>
Looking up function signatures ends up in massive
stderr output which blocks the debugger for ages, so omit
them as long we are not sure where they originate.
Task-number: QTCREATORBUG-25185
Task-number: QTCREATORBUG-25217
Change-Id: I9b022d2194a6cb61651ee0648be526fc94a02da9
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>
This was used uninitialized in some put call from lldbridge's
disassembler.
Change-Id: I5a3ecf075dfd4a6c4e8a483f9f8172e295329ad0
Reviewed-by: David Schulz <david.schulz@qt.io>
And add a QPair dumper doing the same.
Task-number: QTCREATORBUG-25251
Change-Id: Iacff1889c08f7f60ec39d5d5b2b12439b8f8f5d7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
for std::map, std::set and std::list
Fixes: QTCREATORBUG-24901
Change-Id: Ibfb196b17b7270729b052ed27dd51786cb2f8db8
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
