Needs better infrastructure.

Change-Id: I53a53953bd347c296626c03636775f6057faf385
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I33ae39b3bd347c296626c03636775f6057faf385
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ide88fd07e077a158223a68cc504fff5a5b9391ac
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Iea68df0e7077a185223a68cc504fff5a5b9391ac
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ied68fd07e077a185223a68cc504fff5a5b9391ac
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I5f79436b61a3a04de9b7b669bece2204ac858edb
Reviewed-by: hjk <hjk121@nokiamail.com>

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>

Change-Id: I90e93a15b8280a55c31db6be28fe6eb39c7babb0
Reviewed-by: hjk <hjk121@nokiamail.com>

Task-number: QTCREATORBUG-11208

Change-Id: Iec79436b6a13a40de9b7b669bece2204ac858edb
Reviewed-by: Eike Ziller <eike.ziller@digia.com>

Change-Id: I89432915f2b6eb52e706d344b9e7998e1f96ab1f
Reviewed-by: hjk <hjk121@nokiamail.com>

Different quirks on either side...

Change-Id: Ic8d0e66736beb109e9d76da62b73a4d0dd4f38db
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Id8f2ad9e46c88302d523b879558f65b4a86b0e2c
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Idf84b17df0e8ef7796cc50af0b1111d0bde69293
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ib81b82d81dd821be7161eef6515ae1f08091d5e3
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ife3d65cc6617a07dffd43c8ef0f0a734b3f11331
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>

Change-Id: Ib5423fdd064e4546f848c0b640b0ed0514c26d3a
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>

Change-Id: Ibb24ded55ba02b908b63d71f1f872c73ee7b011b
Reviewed-by: Christian Stenger <christian.stenger@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>

Even if it was an empty argument.

Change-Id: I610c4cea82bdbc557e63acd1663040ca70a5d3ee
Reviewed-by: hjk <hjk121@nokiamail.com>

Task-number: QTCREATORBUG-10598
Change-Id: Ia22b46da87b43c807acc11747294609d88c0e183
Reviewed-by: hjk <hjk121@nokiamail.com>

Task-number: QTCREATORBUG-10730
Change-Id: Iab7b46da87b43c807acc11747294609d88c0e183
Reviewed-by: hjk <hjk121@nokiamail.com>

Task-number: QTCREATORBUG-10690
Change-Id: I5deecfed4c525fd6c3cd75f510e7662e469f99ea
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Iaf92f565f9b33f5739bb3e0a19920f160c0b44f7
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>

Change-Id: I1b8396014256afc3845ccdae6e740bbf6059bbf3
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I798396014256afc3845ccdae6e740bbf6059bbf3
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>

Change-Id: I71cfb1e01193c57e06aebeaa8defa11809e24c50
Reviewed-by: Eike Ziller <eike.ziller@digia.com>

Change-Id: I13cfb1e01193c57e06aebeaa8defa11809e24c50
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ie39a38c6646c3c19819e2c122d7f8be285eae09e
Reviewed-by: hjk <hjk121@nokiamail.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>

Change-Id: I139a38c6646c3c19819e2c122d7f8be285eae09e
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I80bfb459c20e92fb0ea4e938421015a09f1c8518
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I4195ad4bf5af3e912f49411acb4bc3a6ec4df33b
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ie7867dce5bd50573d714d41bf46195a802eb61c7
Reviewed-by: Eike Ziller <eike.ziller@digia.com>