GitLab

Change-Id: Id8f2ad9e46c88302d523b879558f65b4a86b0e2c
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
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>

Stop-gap measure until we can properly co-exist.

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

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

More robust.

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

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

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

SBValue has no 'name'

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

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

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

Closer to "production behaviour"

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

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

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

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