gdbbridge.py + dumper.py:
added detection on QNX target and ARM arch
added detection of Qt 3 support
fixed detection of Qt version
qttypes.py:
fixes of different memory alignment
stdtypes.py:
support of different libstdc++ internal structures on QNX
Change-Id: I808ee048c66c73c38bf5a8403e9cf881e767442e
Reviewed-by: hjk <hjk121@nokiamail.com>
Right now its unclear under which circumstances this can
happen, but we should better not abort debugging in such
cases.
Change-Id: Icc3faf304869e6fe13344137c91b0f046edc4a6a
Reviewed-by: hjk <hjk121@nokiamail.com>
Just cosmetics. Function was oddly named, in an odd place.
Change-Id: I8bfb33f7f41f01309f4b2be8a802d4093ae25e41
Reviewed-by: hjk <hjk121@nokiamail.com>
Pretty much the same code for GDB and LLDB, no reason to duplicate.
Change-Id: I4df4ba55e3b6bdfb6422179050f9a31bd1ebe082
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
At least theoretically, on our side. Practically the output
seems to arrive all with ldb.SBProcess.eBroadcastBitSTDOUT
from LLDB.
Change-Id: I61cfb1e01193c57e06aebeaa8defa11809e24c50
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Recent versions of GDB seem to require 'make install' to find their
Python bits. Given that this is not really an option, check the
usual suspects, too.
Change-Id: I5217c0184681d4a86992fe0b8989498843b26cea
Reviewed-by: David Schulz <david.schulz@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
switched to using a relay server
Change-Id: Ic3ddb48b818fa43894314f7fbaf9d7780fc01ade
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
It could entirely miss commands sent by the engine.
The loop was waiting for something to come into stdin, but always only
read a single line from it, although it possibly already contained
multiple lines.
The patch simplifies the loop by removing the select() call entirely
and solely using sys.stdin.readline() which blocks anyhow.
Change-Id: Iff12aa051bb6e11c5ba30081d7c9d4e98940e231
Reviewed-by: hjk <hjk121@nokiamail.com>
gdb.selected_inferior is too new for now.
Change-Id: I4290574b6dd2803a2fd2f860700693e7b2ac6efb
Reviewed-by: Rainer Keller <rainer.keller@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
The previous workaround for the Qt 4 optimized int,uint,short,ushort
QHashNode wasn't working for the QHashNode dumper itself because of
unknown key type. Instead we first try to find the 'key' child directly,
if that fails we look for it in the second child (which would be the
anonymous union from the optimized hash node, which contains the key).
Also fix the expected type for QHashNode in the optimized case for Qt4
Change-Id: Ib48c2c0afec081ff38cd750c3d515a5e678e9661
Reviewed-by: hjk <hjk121@nokiamail.com>
In Qt4 (u)int hashs are optimized and the key is inside an
anonymous union, so, at least with LLDB, we cannot reference
"key" directly as a child of the QHashNode
Change-Id: Id7cac3d08fa85af599f2b2564a6b1f11b465c7b2
Reviewed-by: hjk <hjk121@nokiamail.com>
