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 bitpos value returned by lldb is the bit offset relative to the
beginning of the type, there is no need to do an extra modulus
operation.
Adjust dumper test to add the previously failing case.
The failing case happens when the class containing the bitfield has
more members in front of the bitfield.
Change-Id: I93678f78e6799843558ec53342a0ed49cac74f48
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>
This is achieved by calling "po" on an address value casted to a
simple function pointer type, regardless of the actual type of
the function pointer. lldb does not complain, and reports the
library where the function is defined, its name, and location
in the source code if available.
Change-Id: I23ccce62e33bcf213ccdcb55c9836d54333f3c86
Reviewed-by: hjk <hjk@qt.io>
Judging from the code it either never worked, or LLDB changed
syntax at some time. In either case, having it in a usable
state with current version is an improvement.
Change-Id: I88b15969bf28b92735d860544dedcbd1d9689765
Reviewed-by: Christian Stenger <christian.stenger@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>
... into a EngineShutdownFinished. They were never handled differently,
and the only option is to proceed to DebuggerFinished anyway. So
simplify the state machine a bit.
Change-Id: Ied3be86fff6750abca578dc6788e4be1d895692b
Reviewed-by: David Schulz <david.schulz@qt.io>
The lookup is quite slow, and will hang the lldb debugger,
causing Xcode to hang too.
Change-Id: Ic6579a5de9404c0040d3d304169f18109f61d2ac
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
For some reason sometimes a user stop request with lldb can trigger
a spontaneous stop, avoiding the debugger to stop correctly.
This change fix the issue by emitting the correct states from
lldbbridge.py.
Change-Id: Ib8a2f4875824f4fff426b2d5e0fc4a79ce48c68e
Reviewed-by: hjk <hjk@qt.io>
The LLBD bridge can be imported from the users's ~/.lldbinit:
command script import "<path to lldbbridge.py>"
Or by relying on a (future) debug script in the QtCore dSYM bundle.
Change-Id: Ia099dcebc6375d38ae2d75c939bb5669e30e4b2c
Reviewed-by: hjk <hjk@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>
In certain cases FindFirstType can fail to find a type due to bugs
in lldb. The workaround consists in using FindTypes, and iterating
over the results to find the searched for type.
Change-Id: I1fee3f774d0cf02842f6b55419142af5e9780992
Reviewed-by: hjk <hjk@qt.io>
Needs to make namespace detection work without valid frame
Task-number: QTCREATORBUG-17326
Change-Id: Ia7c7017db4ef384d4f246e11a5601d01f4f366f1
Reviewed-by: hjk <hjk@qt.io>
... and use the option to govern general QObject guts display.
This allows people to completely avoid the performance impact
of attempted QObject display and still makes the feature
more prominent for our favorite use case.
Change-Id: I1e53b6448f646ab7eea9168a3cd24c77769e6328
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
A truly empty base wouldn't need content, but LLDB 3.8 reports declared
but not defined undistinguishable from empty bases. At least for the
common case of a single inheritance class we can continue dumping by
fake base class contents by fake the contents by using the whole derived
object's data.
Change-Id: I82d595b985ec1289d8abce5fccd217057d2d2d44
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The 'output' bit is inserted at report time, not at callback
script generation time.
Change-Id: Ibb5c9b09d8391d1be86b8f110e32ab1c90f6bab2
Reviewed-by: David Schulz <david.schulz@qt.io>
It has a function directly doing that, use it instead of
guessing (badly, in some cases)
Change-Id: I1ce317c28d60f820f8e868e3c0c5a665f8de6cb7
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
They are not usable in core files.
Change-Id: I2134b61f27c27862c12a679d0acf7bebc9fcc7a2
Reviewed-by: Orgad Shaneh <orgads@gmail.com>
Reviewed-by: hjk <hjk@qt.io>
Use the fact that the order of the first three vtable entries of a
QObject is fixed and the size of their implementations is roughly
known.
Change-Id: I3d13f594cb1c1f162a520da18b2bc2aaba852092
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
This is a partial revert of the type id change (bd2653fb) to get
the case of virtual bases work again, as it falls back to native
field accesses everywhere we have native types.
This is likely to be a performance regression with CDB/Python,
but since this combination is experimental and not used by
default in 4.2 getting GDB/LLDB right is more important.
Medium term we might want to have a more fine-grained approach
to use of type ids (e.g. use native field accesses on a case-by
-case base only for type with virtual inheritance)
Change-Id: I239111e6ce5f3365b750068bfc4dafb12be1d53c
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Use the field's type size if the reported field size is 0.
Change-Id: I7db49507d0ea7358b6db27dfa206f2b079bbf876
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
There seems to be race in the LLDB setup on Linux. Work around
by not doing serious work twice to be able to use the test at least.
Change-Id: I387a57d3c66e6c4209bd424af9be16f17acb98fa
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
