The actual problem is that LLDB considers types that differ
only in spacing of the "name" (i.e. "foo *" and "foo*") as
different and can not look them up with the "wrong" name.
Change-Id: Iff79436b6a13a40de9b7b669bece2204ac858edb
Reviewed-by: hjk <hjk121@nokiamail.com>
Make backend-agnostic and use it for QFiniteStack and
std::{array,vector}
Change-Id: I1702d4290ee24c957f77b539591313ac83021003
Reviewed-by: hjk <hjk121@nokiamail.com>
Correctly use the device specific cached symbols to avoid downloading
them from the device (big slowdown).
Task-number: QTCREATORBUG-10884
Change-Id: Ic82482e4b1dadf55f695a67fd420ac1b095a3ca1
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
It was only showing the "last" one because the inames were the same
(currentIName.None).
Do not overwrite iname of sub item in 'enterSubItem' if it already was
set.
Task-number: QTCREATORBUG-11109
Change-Id: I74581f62d47ff0c33650769c3ed66e24124d1092
Reviewed-by: hjk <hjk121@nokiamail.com>
The integration was only doing that for breakpoints, but not for
stepping etc.
Task-number: QTCREATORBUG-10813
Change-Id: I4be7ec691e839bf062ab67587062cba00cc85e4f
Reviewed-by: hjk <hjk121@nokiamail.com>
the attached process is seen as still running just after the attach
and continuing fails, immediately later a spontaneous stop is
detected and on ios (where we set continueAfterAttach) we
continue after the spontanous stop.
This also work in the desktop case.
Change-Id: I92fbcd3ba319da7d9e664f67c8cbbea00f0daa43
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>
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>
That also makes lldb dumper actually test for bitness instead of
assuming 64bit
Change-Id: I6207bac04817e1f4700247dc00d2dfdace1e5100
Reviewed-by: hjk <hjk121@nokiamail.com>
