(except gdbmi.cpp, name_demangler.cpp). Remove some unneeded
conversions, change some maps to take QByteArray keys.
Change-Id: I010f1251998a441fe5c8c87901b1e0c277c0391c
Reviewed-by: hjk <qthjk@ovi.com>
For memory views. In the dumper, create a cache of TypeInfo
structs to contain type information and print the new entries
in each call of bb().
Collect the information in the gdb engine.
Replace WatchData::origAddress by WatchData::ReferencingAddress
to be able to correctly handle automatically dereferenced
pointers of the gdb engine. Whereas 'address' of a automatically
dereferenced used to be that of the pointer, it is now that
of the dereferenced item matching the size reported, enabling
memory views. Referencing address is now the address of the pointer.
Reviewed-by: hjk
Fix name formatting and algorithm to find uninitialized
variables to use reverse order in case locals of the same
name occur in a scope.
Reviewed-by: hjk
Task-number: QTCREATORBUG-4475
Use a quint64 as address. Split apart special handling of
QAbstractItemModels of old shared-library based dumpers
(passing '$'+ special expression as address) into separate
dumperFlags QByteArray.
This replaces the (de facto) singleton engines and data handlers by classes
that are instantiated per run. The DebuggerRunControl will now create an
object of (a class derived from) DebuggerEngine that contains all the relevant
"dynamic" data.
DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
whereas the data bits went to DebuggerEngine.
There is no formal notion of a "current" DebuggerEngine. However, as there's
only one DebuggerEngine at a time that has its data models connected to the
view, there's still some "de facto" notion of a "current" engine. Calling
SomeModel::setData(int role, QVariant data) with custom role is used as the
primary dispatch mechanism from the views to the "current" data models
(and the engine, as all data models know their engine).
