feedc0de/qt-creator
1
0
Fork 0
forked from qt-creator/qt-creator
Code Pull Requests Activity
Files
75a9d6961c64ac9feaf1a66fea2eab9f054c85f1
qt-creator/src/plugins/debugger/debuggerengine.h

416 lines
14 KiB
C
Raw Normal View History

debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
/**************************************************************************
**
** This file is part of Qt Creator
**
It's 2011 now. Reviewed-by: hjk
2011-01-11 16:28:15 +01:00
** Copyright (c) 2011 Nokia Corporation and/or its subsidiary(-ies).
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
**
all: s/info@qt.nokia.com/qt-info@nokia.com/ Change-Id: If18afb5d4665924e7d9250dccbc60a65e6daa75e Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
2011-11-02 15:59:12 +01:00
** Contact: Nokia Corporation (qt-info@nokia.com)
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
**
**
** GNU Lesser General Public License Usage
**
Update license.
2011-04-13 08:42:33 +02:00
** This file may be used under the terms of the GNU Lesser General Public
** License version 2.1 as published by the Free Software Foundation and
** appearing in the file LICENSE.LGPL included in the packaging of this file.
** Please review the following information to ensure the GNU Lesser General
** Public License version 2.1 requirements will be met:
** http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html.
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
**
License headers.
2010-12-17 16:01:08 +01:00
** In addition, as a special exception, Nokia gives you certain additional
Update license.
2011-04-13 08:42:33 +02:00
** rights. These rights are described in the Nokia Qt LGPL Exception
License headers.
2010-12-17 16:01:08 +01:00
** version 1.1, included in the file LGPL_EXCEPTION.txt in this package.
**
Update license.
2011-04-13 08:42:33 +02:00
** Other Usage
**
** Alternatively, this file may be used in accordance with the terms and
** conditions contained in a signed written agreement between you and Nokia.
**
License headers.
2010-12-17 16:01:08 +01:00
** If you have questions regarding the use of this file, please contact
all: s/info@qt.nokia.com/qt-info@nokia.com/ Change-Id: If18afb5d4665924e7d9250dccbc60a65e6daa75e Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
2011-11-02 15:59:12 +01:00
** Nokia at qt-info@nokia.com.
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
**
**************************************************************************/
#ifndef DEBUGGER_DEBUGGERENGINE_H
#define DEBUGGER_DEBUGGERENGINE_H
#include "debugger_global.h"
#include "debuggerconstants.h"
debugger: Refactor breakpoint handling. 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.
2010-11-10 16:33:11 +01:00
#include "breakpoint.h" // For 'BreakpointId'
overhaul process argument handling get away from argument stringlists. instead, use native shell command lines which support quoting/splitting, environment variable expansion and redirections with well-understood semantics. Task-number: QTCREATORBUG-542 Task-number: QTCREATORBUG-1564
2010-10-19 11:14:03 +02:00
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
#include <QtCore/QObject>
#include <QtCore/QStringList>
QT_BEGIN_NAMESPACE
class QDebug;
class QPoint;
debugger: move convienience function to DebuggerEngine base class
2010-07-21 14:24:29 +02:00
class QMessageBox;
Debugger: Header cleanup
2011-01-10 10:14:23 +01:00
class QAbstractItemModel;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
QT_END_NAMESPACE
namespace TextEditor {
class ITextEditor;
}
namespace Core {
class IOptionsPage;
}
namespace Debugger {
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
class DebuggerEnginePrivate;
debugger: kill command handler & company
2010-11-08 15:19:13 +01:00
class DebuggerRunControl;
Debugger: Header cleanup
2011-01-10 10:14:23 +01:00
class DebuggerStartParameters;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
DEBUGGER_EXPORT QDebug operator<<(QDebug str, const DebuggerStartParameters &);
DEBUGGER_EXPORT QDebug operator<<(QDebug str, DebuggerState state);
namespace Internal {
debugger: refactoring of the plugin interface There's some 'external' and some 'internal' part now. Other plugins are only supposed the external interface.
2010-11-10 11:39:01 +01:00
class DebuggerPluginPrivate;
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
class DisassemblerAgent;
class MemoryAgent;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
class WatchData;
class BreakHandler;
class ModulesHandler;
class RegisterHandler;
class StackHandler;
class StackFrame;
class SourceFilesHandler;
class ThreadsHandler;
class WatchHandler;
debugger: remove intermediate BreakpointData stucture layer
2010-11-16 11:48:17 +01:00
class BreakpointParameters;
debugger: mover qml related engines to the Internal namespace
2010-12-03 12:07:32 +01:00
class QmlCppEngine;
Debugger: Make tooltips pinnable. 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
2011-02-11 15:00:13 +01:00
class DebuggerToolTipContext;
Debugger: Use bin editor widget for standalone-memory views. Remove MemoryViewWidget/RegisterMemoryViewWidget in favour of MemoryView/RegisterMemoryView based on the bin editor widget.
2011-04-19 12:17:48 +02:00
class MemoryMarkup;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
debugger: only update variables that are operated on
2010-09-13 08:32:12 +02:00
struct WatchUpdateFlags
{
WatchUpdateFlags() : tryIncremental(false) {}
bool tryIncremental;
};
debugger: kill command handler & company
2010-11-08 15:19:13 +01:00
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
class Location
{
public:
Location() { init(); }
Location(quint64 address) { init(); m_address = address; }
Location(const QString &file) { init(); m_fileName = file; }
Location(const QString &file, int line, bool marker = true)
{ init(); m_lineNumber = line; m_fileName = file; m_needsMarker = marker; }
Debugger: Header cleanup
2011-01-10 10:14:23 +01:00
Location(const StackFrame &frame, bool marker = true);
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
QString fileName() const { return m_fileName; }
QString functionName() const { return m_functionName; }
Debugger[CDB]: Display more context in disassembly. Emulate gdb's behaviour trying to disassemble the function. Task-number: QTCREATORBUG-5205 Change-Id: I2f4dc9393e12324b0423734c5235758a25395fec Reviewed-on: http://codereview.qt.nokia.com/1029 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-07-04 09:29:28 +02:00
QString from() const { return m_from; }
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
int lineNumber() const { return m_lineNumber; }
void setNeedsRaise(bool on) { m_needsRaise = on; }
void setNeedsMarker(bool on) { m_needsMarker = on; }
void setFileName(const QString &fileName) { m_fileName = fileName; }
bool needsRaise() const { return m_needsRaise; }
bool needsMarker() const { return m_needsMarker; }
bool hasDebugInfo() const { return m_hasDebugInfo; }
quint64 address() const { return m_address; }
private:
void init() { m_needsMarker = false; m_needsRaise = true; m_lineNumber = -1;
m_address = 0; m_hasDebugInfo = true; }
bool m_needsMarker;
bool m_needsRaise;
bool m_hasDebugInfo;
int m_lineNumber;
QString m_fileName;
QString m_functionName;
Debugger[CDB]: Display more context in disassembly. Emulate gdb's behaviour trying to disassemble the function. Task-number: QTCREATORBUG-5205 Change-Id: I2f4dc9393e12324b0423734c5235758a25395fec Reviewed-on: http://codereview.qt.nokia.com/1029 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-07-04 09:29:28 +02:00
QString m_from;
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
quint64 m_address;
};
debugger: fix 'Jump To/Run to' when in instruction-wise mode
2011-02-23 10:16:11 +01:00
class ContextData
{
public:
ContextData() : lineNumber(0), address(0) {}
public:
QString fileName;
int lineNumber;
quint64 address;
};
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
} // namespace Internal
debugger: only update variables that are operated on
2010-09-13 08:32:12 +02:00
debugger: kill command handler & company
2010-11-08 15:19:13 +01:00
debugger: incorporate ogoffart's first shot at qml debugging
2010-06-25 14:08:53 +02:00
// FIXME: DEBUGGER_EXPORT?
class DEBUGGER_EXPORT DebuggerEngine : public QObject
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
{
Q_OBJECT
public:
debugger: introduce generic master/slaves engine
2011-01-12 12:10:12 +01:00
explicit DebuggerEngine(const DebuggerStartParameters &sp,
Debugger: Expose which languages (QML, C++, Any) an engine supports Change-Id: Ia690b5cda84738c303ae7b6bd579e43313728525 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-10-12 16:28:33 +02:00
DebuggerLanguages languages,
debugger: introduce generic master/slaves engine
2011-01-12 12:10:12 +01:00
DebuggerEngine *parentEngine = 0);
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
virtual ~DebuggerEngine();
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
const DebuggerStartParameters &startParameters() const;
DebuggerStartParameters &startParameters();
Debugger: Reduce tooltip flicker. Move tooltip-request handling from DebuggerPlugin into DebuggerToolTipManager. Request tooltip only if position changed and close standard tooltip on success.
2011-02-17 10:08:57 +01:00
virtual bool setToolTipExpression(const QPoint & mousePos,
Debugger: Make tooltips pinnable. 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
2011-02-11 15:00:13 +01:00
TextEditor::ITextEditor *editor, const Internal::DebuggerToolTipContext &);
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void updateWatchData(const Internal::WatchData &data,
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +02:00
const Internal::WatchUpdateFlags & flags = Internal::WatchUpdateFlags());
debugger: introduce generic master/slaves engine
2011-01-12 12:10:12 +01:00
virtual void startDebugger(DebuggerRunControl *runControl);
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void watchPoint(const QPoint &);
Debugger: Use bin editor widget for standalone-memory views. Remove MemoryViewWidget/RegisterMemoryViewWidget in favour of MemoryView/RegisterMemoryView based on the bin editor widget.
2011-04-19 12:17:48 +02:00
enum MemoryViewFlags
{
MemoryReadOnly = 0x1, //!< Read-only.
MemoryTrackRegister = 0x2, //!< Address parameter is register number to track
MemoryView = 0x4 //!< Open a separate view (using the pos-parameter).
};
virtual void openMemoryView(quint64 startAddr, unsigned flags,
const QList<Internal::MemoryMarkup> &ml,
const QPoint &pos,
const QString &title = QString(), QWidget *parent = 0);
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
virtual void fetchMemory(Internal::MemoryAgent *, QObject *,
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
quint64 addr, quint64 length);
debugger: work on writable memory view
2011-02-25 13:21:54 +01:00
virtual void changeMemory(Internal::MemoryAgent *, QObject *,
quint64 addr, const QByteArray &data);
debugger: move MemoryViewAgent ownership to DebuggerEngine
2010-12-13 18:17:31 +01:00
virtual void updateMemoryViews();
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
virtual void openDisassemblerView(const Internal::Location &location);
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
virtual void fetchDisassembler(Internal::DisassemblerAgent *);
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void activateFrame(int index);
virtual void reloadModules();
virtual void examineModules();
virtual void loadSymbols(const QString &moduleName);
debugger: add an option to load "missing" symbols for current stack
2010-12-21 13:34:59 +01:00
virtual void loadSymbolsForStack();
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void loadAllSymbols();
virtual void requestModuleSymbols(const QString &moduleName);
virtual void reloadRegisters();
virtual void reloadSourceFiles();
virtual void reloadFullStack();
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
virtual void setRegisterValue(int regnr, const QString &value);
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void addOptionPages(QList<Core::IOptionsPage*> *) const;
debugger: replace static capability check by something potentially dynamic This does not yet use the potential. Change-Id: I087311fb7d59b46e49f65a84c4420c72a1227ebb Reviewed-by: Aurindam Jana <aurindam.jana@nokia.com>
2012-01-12 20:28:17 +01:00
virtual bool hasCapability(unsigned cap) const = 0;
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual bool isSynchronous() const;
virtual QByteArray qtNamespace() const;
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void createSnapshot();
virtual void updateAll();
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
typedef Internal::BreakpointModelId BreakpointModelId;
debugger: Refactor breakpoint handling. 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.
2010-11-10 16:33:11 +01:00
virtual bool stateAcceptsBreakpointChanges() const { return true; }
virtual void attemptBreakpointSynchronization();
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
virtual bool acceptsBreakpoint(BreakpointModelId id) const = 0;
virtual void insertBreakpoint(BreakpointModelId id); // FIXME: make pure
virtual void removeBreakpoint(BreakpointModelId id); // FIXME: make pure
virtual void changeBreakpoint(BreakpointModelId id); // FIXME: make pure
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
debugger: replace action(ExecuteCommand) be a direct function call
2011-02-16 12:41:06 +01:00
virtual bool acceptsDebuggerCommands() const { return true; }
debugger: kill command handler & company
2010-11-08 15:19:13 +01:00
virtual void assignValueInDebugger(const Internal::WatchData *data,
const QString &expr, const QVariant &value);
debugger: Refactor breakpoint handling. 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.
2010-11-10 16:33:11 +01:00
virtual void selectThread(int index);
debugger: move convienience function to DebuggerEngine base class
2010-07-21 14:24:29 +02:00
debugger: structural cleanup remote debugging Use virtual function instead of if/qobject_cast cascades.
2010-12-10 12:41:44 +01:00
virtual void handleRemoteSetupDone(int gdbServerPort, int qmlPort);
virtual void handleRemoteSetupFailed(const QString &message);
debugger: introduce generic master/slaves engine
2011-01-12 12:10:12 +01:00
virtual Internal::ModulesHandler *modulesHandler() const;
virtual Internal::RegisterHandler *registerHandler() const;
virtual Internal::StackHandler *stackHandler() const;
virtual Internal::ThreadsHandler *threadsHandler() const;
virtual Internal::WatchHandler *watchHandler() const;
virtual Internal::SourceFilesHandler *sourceFilesHandler() const;
virtual Internal::BreakHandler *breakHandler() const;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
Qml Debugger: Enable debugging qml+cpp standalone applications A new debugger engine, QmlCppEngine, is introduced, which wraps gdb and qml engines into one. Alternatively, if using Windows, Cdb is used instead of Gdb. Most of the debugger ui switcher is now rewritten, and it is tailored for the QML and CPP layout case, the only one supported anyway. Reviewed-by: hjk
2010-08-18 13:54:12 +02:00
virtual QAbstractItemModel *modulesModel() const;
virtual QAbstractItemModel *registerModel() const;
virtual QAbstractItemModel *stackModel() const;
virtual QAbstractItemModel *threadsModel() const;
virtual QAbstractItemModel *localsModel() const;
virtual QAbstractItemModel *watchersModel() const;
virtual QAbstractItemModel *returnModel() const;
Debugger: Make tooltips pinnable. 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
2011-02-11 15:00:13 +01:00
virtual QAbstractItemModel *toolTipsModel() const;
Qml Debugger: Enable debugging qml+cpp standalone applications A new debugger engine, QmlCppEngine, is introduced, which wraps gdb and qml engines into one. Alternatively, if using Windows, Cdb is used instead of Gdb. Most of the debugger ui switcher is now rewritten, and it is tailored for the QML and CPP layout case, the only one supported anyway. Reviewed-by: hjk
2010-08-18 13:54:12 +02:00
virtual QAbstractItemModel *sourceFilesModel() const;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
debugger: move progress handling to debugger engine base class
2010-07-21 11:02:51 +02:00
void progressPing();
debugger: restore session breakpoints if RunControl finishes
2010-06-22 15:14:44 +02:00
void handleFinished();
debugger: make debugger restartable using the buttons in the application output pane
2010-07-20 18:31:35 +02:00
void handleStartFailed();
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
bool debuggerActionsEnabled() const;
static bool debuggerActionsEnabled(DebuggerState state);
DebuggerState state() const;
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
DebuggerState lastGoodState() const;
DebuggerState targetState() const;
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
bool isDying() const;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
// Dumper stuff (common to cdb and gdb).
bool qtDumperLibraryEnabled() const;
QString qtDumperLibraryName() const;
QStringList qtDumperLibraryLocations() const;
debugger: attempt to re-try examining dumper location after build. Still does not work as the location itself is unknown.
2010-07-21 12:04:20 +02:00
void showQtDumperLibraryWarning(const QString &details);
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
static const char *stateName(int s);
void notifyInferiorPid(qint64 pid);
qint64 inferiorPid() const;
bool isReverseDebugging() const;
debugger: more breakpoint management related fixes
2010-06-22 15:37:27 +02:00
void handleCommand(int role, const QVariant &value);
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
// Convenience
QmlDebug: Parse application output to track debugees state Setting up the debugger connection might fail for a couple of reasons. Check the application output to show the user a more detailed error message. Reviewed-by: hjk
2011-02-21 17:01:40 +01:00
Q_SLOT virtual void showMessage(const QString &msg, int channel = LogDebug,
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
int timeout = -1) const;
Fix CDB/trkgdbadapter.
2010-07-14 16:01:53 +02:00
Q_SLOT void showStatusMessage(const QString &msg, int timeout = -1) const;
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
QmlCppEngine: Make sure that breakpoint markers get removed resetLocation() called by DebuggerPlugin::handle* should automatically reset the locations for stepping etc. Change-Id: I3e20f93ade7f40e1e1f33b1b48b11522b59771f8 Task-number: QTCREATORBUG-6291 Reviewed-by: Christiaan Janssen <christiaan.janssen@nokia.com>
2011-10-12 17:26:18 +02:00
virtual void resetLocation();
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
virtual void gotoLocation(const Internal::Location &location);
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
virtual void quitDebugger(); // called by DebuggerRunControl
debugger: cleaner debugger aborting Make the second "Abort Debugger" kill the gdb process directly instead of relying on further communication. Also fix some "unexpected" (but harmless) state transitions. Change-Id: I0938ec76420fbd77ec4b7348819dd7f63763547f Reviewed-by: hjk <qthjk@ovi.com>
2011-10-31 17:36:08 +01:00
virtual void abortDebugger(); // called by DebuggerPlugin
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +02:00
virtual void updateViews();
x
2010-10-28 08:55:50 +02:00
bool isSlaveEngine() const;
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
bool isMasterEngine() const;
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
DebuggerEngine *masterEngine() const;
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +02:00
Debugger: Expose which languages (QML, C++, Any) an engine supports Change-Id: Ia690b5cda84738c303ae7b6bd579e43313728525 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-10-12 16:28:33 +02:00
DebuggerLanguages languages() const;
debugger: implement qml->c++ cross-stepping
2011-01-19 14:34:25 +01:00
virtual bool setupQmlStep(bool /*on*/) { return false; }
virtual void readyToExecuteQmlStep() {}
debugger: first shot at combined cpp/qml stepping
2011-01-14 17:08:59 +01:00
QmlDebugger: displaying tooltips while qml is running Reviewed-by: hjk
2011-01-24 16:58:35 +01:00
virtual bool canDisplayTooltip() const { return state() == InferiorStopOk; }
Maemo: Inform debugger engine about connection loss. Task-number: QTCREATORBUG-3783
2011-02-11 14:20:23 +01:00
virtual void notifyInferiorIll();
Qml Debugger: Enable debugging qml+cpp standalone applications A new debugger engine, QmlCppEngine, is introduced, which wraps gdb and qml engines into one. Alternatively, if using Windows, Cdb is used instead of Gdb. Most of the debugger ui switcher is now rewritten, and it is tailored for the QML and CPP layout case, the only one supported anyway. Reviewed-by: hjk
2010-08-18 13:54:12 +02:00
signals:
Debugger: Fully qualify signals.
2011-02-04 16:07:58 +01:00
void stateChanged(const Debugger::DebuggerState &state);
Debugger: Make tooltips pinnable. 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
2011-02-11 15:00:13 +01:00
// A new stack frame is on display including locals.
void stackFrameCompleted();
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +02:00
void updateViewsRequested();
debugger: structural cleanup remote debugging Use virtual function instead of if/qobject_cast cascades.
2010-12-10 12:41:44 +01:00
/*
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
* For "external" clients of a debugger run control that needs to do
debugger: structural cleanup remote debugging Use virtual function instead of if/qobject_cast cascades.
2010-12-10 12:41:44 +01:00
* further setup before the debugger is started (e.g. Maemo).
Debugger: Fix method names in comment Change-Id: I269fdecce845f3cc0e8b70fbf5f7278a0eb00910 Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
2012-01-13 15:01:44 +01:00
* Afterwards, handleRemoteSetupDone() or handleRemoteSetupFailed() must be called
debugger: structural cleanup remote debugging Use virtual function instead of if/qobject_cast cascades.
2010-12-10 12:41:44 +01:00
* to continue or abort debugging, respectively.
* This signal is only emitted if the start parameters indicate that
* a server start script should be used, but none is given.
*/
void requestRemoteSetup();
Qml Debugger: Enable debugging qml+cpp standalone applications A new debugger engine, QmlCppEngine, is introduced, which wraps gdb and qml engines into one. Alternatively, if using Windows, Cdb is used instead of Gdb. Most of the debugger ui switcher is now rewritten, and it is tailored for the QML and CPP layout case, the only one supported anyway. Reviewed-by: hjk
2010-08-18 13:54:12 +02:00
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
protected:
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
// The base notify*() function implementation should be sufficient
// in most cases, but engines are free to override them to do some
// engine specific cleanup like stopping timers etc.
virtual void notifyEngineSetupOk();
virtual void notifyEngineSetupFailed();
virtual void notifyEngineRunFailed();
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyInferiorSetupOk();
virtual void notifyInferiorSetupFailed();
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyEngineRunAndInferiorRunOk();
virtual void notifyEngineRunAndInferiorStopOk();
virtual void notifyInferiorUnrunnable(); // Called by CoreAdapter.
debugger: more state work
2010-07-13 08:41:27 +02:00
// Use notifyInferiorRunRequested() plus notifyInferiorRunOk() instead.
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
//virtual void notifyInferiorSpontaneousRun();
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyInferiorRunRequested();
virtual void notifyInferiorRunOk();
virtual void notifyInferiorRunFailed();
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyInferiorStopOk();
virtual void notifyInferiorSpontaneousStop();
virtual void notifyInferiorStopFailed();
virtual void notifyInferiorExited();
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyInferiorShutdownOk();
virtual void notifyInferiorShutdownFailed();
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyEngineSpontaneousShutdown();
virtual void notifyEngineShutdownOk();
virtual void notifyEngineShutdownFailed();
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
debugger: cleanup gdb command queue when inferior setup failed
2010-08-11 09:46:39 +02:00
virtual void notifyEngineIll();
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
debugger: overhaul "state machine" This mainly allows for more precise shutdown and tightens the set of allowed transitions.
2010-07-09 17:07:59 +02:00
virtual void setupEngine() = 0;
virtual void setupInferior() = 0;
virtual void runEngine() = 0;
virtual void shutdownInferior() = 0;
virtual void shutdownEngine() = 0;
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
virtual void detachDebugger();
virtual void exitDebugger();
virtual void executeStep();
debugger: cleaner debugger aborting Make the second "Abort Debugger" kill the gdb process directly instead of relying on further communication. Also fix some "unexpected" (but harmless) state transitions. Change-Id: I0938ec76420fbd77ec4b7348819dd7f63763547f Reviewed-by: hjk <qthjk@ovi.com>
2011-10-31 17:36:08 +01:00
virtual void executeStepOut();
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
virtual void executeNext();
virtual void executeStepI();
virtual void executeNextI();
virtual void executeReturn();
virtual void continueInferior();
virtual void interruptInferior();
virtual void requestInterruptInferior();
debugger: fix 'Jump To/Run to' when in instruction-wise mode
2011-02-23 10:16:11 +01:00
virtual void executeRunToLine(const Internal::ContextData &data);
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
virtual void executeRunToFunction(const QString &functionName);
debugger: fix 'Jump To/Run to' when in instruction-wise mode
2011-02-23 10:16:11 +01:00
virtual void executeJumpToLine(const Internal::ContextData &data);
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
virtual void executeDebuggerCommand(const QString &command);
virtual void frameUp();
virtual void frameDown();
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
DebuggerRunControl *runControl() const;
debugger: code cosmetics
2010-07-08 15:06:09 +02:00
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
static QString msgWatchpointByAddressTriggered(BreakpointModelId id,
debugger: polish module symbols
2010-11-26 09:58:34 +01:00
int number, quint64 address);
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
static QString msgWatchpointByAddressTriggered(BreakpointModelId id,
debugger: polish module symbols
2010-11-26 09:58:34 +01:00
int number, quint64 address, const QString &threadId);
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
static QString msgWatchpointByExpressionTriggered(BreakpointModelId id,
debugger: work on watchpoints (or, "data breakpoints" as they are called now)
2011-05-10 15:57:33 +02:00
int number, const QString &expr);
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
static QString msgWatchpointByExpressionTriggered(BreakpointModelId id,
debugger: work on watchpoints (or, "data breakpoints" as they are called now)
2011-05-10 15:57:33 +02:00
int number, const QString &expr, const QString &threadId);
debugger: split BreakpointIndex into plugin and debugger specific part Change-Id: I21d10cf42eb039c74475e106537b6e107d155196 Reviewed-on: http://codereview.qt.nokia.com/745 Reviewed-by: hjk <qthjk@ovi.com>
2011-06-24 16:25:30 +02:00
static QString msgBreakpointTriggered(BreakpointModelId id,
debugger: polish module symbols
2010-11-26 09:58:34 +01:00
int number, const QString &threadId);
Debugger: Introduce common messages to engine. Try to achieve consistency in reporting stop messages for all engines. Report by BreakpointId if available.
2010-11-17 17:16:34 +01:00
static QString msgStopped(const QString &reason = QString());
static QString msgStoppedBySignal(const QString &meaning, const QString &name);
debugger: polish module symbols
2010-11-26 09:58:34 +01:00
static QString msgStoppedByException(const QString &description,
const QString &threadId);
Debugger: Introduce common messages to engine. Try to achieve consistency in reporting stop messages for all engines. Report by BreakpointId if available.
2010-11-17 17:16:34 +01:00
static QString msgInterrupted();
debugger: polish module symbols
2010-11-26 09:58:34 +01:00
void showStoppedBySignalMessageBox(const QString meaning, QString name);
Debugger: Introduce common messages to engine. Try to achieve consistency in reporting stop messages for all engines. Report by BreakpointId if available.
2010-11-17 17:16:34 +01:00
void showStoppedByExceptionMessageBox(const QString &description);
Debugger: Fix compilation, centralize breakpoint type detection. Reviewed-by: hjk
2010-11-26 13:06:03 +01:00
static bool isCppBreakpoint(const Internal::BreakpointParameters &p);
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
bool isStateDebugging() const;
void setStateDebugging(bool on);
debugger: some start up state consolidation
2011-01-14 18:16:40 +01:00
virtual void setupSlaveInferior();
virtual void setupSlaveEngine();
virtual void runSlaveEngine();
virtual void shutdownSlaveEngine();
debugger: slaveEngineStateChanged should and can now be private
2011-01-17 10:07:13 +01:00
virtual void slaveEngineStateChanged(DebuggerEngine *engine,
DebuggerState state);
debugger: start automization of manual tests Change-Id: I33bd046eca253130049d0a80de7a1a3f3e442307 Reviewed-by: hjk <qthjk@ovi.com>
2011-11-25 16:29:25 +01:00
virtual void handleAutoTests();
debugger: work on action handling
2010-06-22 17:18:29 +02:00
private:
debugger: make DebuggerEngine::setState private.
2010-11-18 17:37:56 +01:00
// Wrapper engine needs access to state of its subengines.
debugger: mover qml related engines to the Internal namespace
2010-12-03 12:07:32 +01:00
friend class Internal::QmlCppEngine;
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
friend class Internal::DebuggerPluginPrivate;
QmlDebugger: bypassing jsdebugger stop when querying expressions Reviewed-by: Kai Koehne
2011-01-24 16:30:34 +01:00
friend class QmlAdapter;
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
virtual void setState(DebuggerState state, bool forced = false);
debugger: make DebuggerEngine::setState private.
2010-11-18 17:37:56 +01:00
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
friend class DebuggerEnginePrivate;
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
DebuggerEnginePrivate *d;
};
} // namespace Debugger
debugger: fix 'Jump To/Run to' when in instruction-wise mode
2011-02-23 10:16:11 +01:00
Q_DECLARE_METATYPE(Debugger::Internal::ContextData)
debugger: The DebuggerEngine refactoring. 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).
2010-06-16 11:08:54 +02:00
#endif // DEBUGGER_DEBUGGERENGINE_H
Copy Permalink