By source - latin1 is really expected as there is no any check
or usage of QTextCodec::setCodecForCStrings() currently.
QString::fromAscii() might break 'Latin1' input in some cases.
A quote from documentation about QString::fromAscii():
"Note that, despite the name, this function actually uses the
codec defined by QTextCodec::setCodecForCStrings() to convert str
to Unicode. Depending on the codec, it may not accept valid
US-ASCII (ANSI X3.4-1986) input. If no codec has been set, this
function does the same as fromLatin1()."
Change-Id: I49cf047ca674d2ec621b517c635d1927bb2e796f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: hjk <qthjk@ovi.com>
Getting the #include directives ready for Qt5. This includes the
new-project wizards.
Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
(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>
Warn if the condition fails, but otherwise don't change the execution
flow.
Change-Id: Id7b14c745109b66960add967b2a4ef8d31e1a546
Reviewed-on: http://codereview.qt.nokia.com/2389
Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
Use proper QByteArray member in GdbResponse instead. Less magic, and
does not break array-style reponses where all children are assumed to
be of the same "type".
Change-Id: Ief1efdeb0412f59836e1b2d6f4cb751ddef3216e
Reviewed-on: http://codereview.qt.nokia.com/1184
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Eike Ziller <eike.ziller@nokia.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
Replace old debugger tooltip by a new ToolTipManager which
has a list of AbstractDebuggerToolTipWidget with the functionality
to 'acquire' an engine (display its data) and 'release' it
(store engine data and display them as 'previous') and serialization
to XML session data.
DebuggerTreeViewToolTipWidget implements AbstractDebuggerToolTipWidget
for tree model acting as a filter on watch models.
Rubber-stamped-by: hjk
The breakpoints are now (fairly) tightly guarded by the BreakpointHandler.
Engines and Views are only supposed to refer to them by id. They also have
individual states now. The breakpoint data is split into a "user requested"
"fixed" part in BreakpointData and the engines' acknowledged data in a new
struct BreakpointResponse.
TODO: Move m_state and m_engine members to BreakpointResponse. Fix regressions
in the marker handling.
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).
This replaces most uses of DebuggerStartParameters by DebuggerRunControl
which is a simple RunControl with a DebuggerStartParameters member.
Plan is to move all global state to the run controls, and possibly
introduce specialized ones for core debugging etc.
