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

350 lines
11 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
**
** Copyright (c) 2010 Nokia Corporation and/or its subsidiary(-ies).
**
** Contact: Nokia Corporation (qt-info@nokia.com)
**
** Commercial Usage
**
** Licensees holding valid Qt Commercial licenses may use this file in
** accordance with the Qt Commercial License Agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and Nokia.
**
** GNU Lesser General Public License Usage
**
** Alternatively, 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.
**
** If you are unsure which license is appropriate for your use, please
** contact the sales department at http://qt.nokia.com/contact.
**
**************************************************************************/
#ifndef DEBUGGER_DEBUGGERENGINE_H
#define DEBUGGER_DEBUGGERENGINE_H
#include "debugger_global.h"
#include "debuggerconstants.h"
#include "moduleshandler.h" // For 'Symbols'
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'
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 <coreplugin/ssh/sshconnection.h>
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
#include <utils/environment.h>
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: 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: 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 QmlCppEngine;
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 DEBUGGER_EXPORT DebuggerStartParameters
{
public:
DebuggerStartParameters();
void clear();
QString executable;
QString displayName;
QString coreFile;
debugger: don't remove corefiles that we did not create.
2010-09-07 14:19:44 +02:00
bool isSnapshot; // set if created internally
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
QString processArgs;
Utils::Environment environment;
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
QString workingDirectory;
qint64 attachPID;
bool useTerminal;
bool breakAtMain;
QString crashParameter; // for AttachCrashedExternal
Maemo: Complete support for debugging via remote gdb. 1) Make sources available on device. 2) Enable users to switch between gdb and gdbserver approach (users may not be able to use the former if they have no control over their firewall). Reviewed-by: kh1
2010-07-30 12:14:54 +02:00
QML Debugger refactoring Now, QmlEngine creates the connection to the inferior (debuggee), and notifies QmlInspector when a connection is established. Before, inspector created the debugger engin, which was wrong. QmlEngine's responsibilities are connecting to the debuggee and basic QML/JS debugging features like locals & watchers, breakpoints etc. QmlInspector takes care of Live Preview and other fancy inspection features. Reviewed-by: hjk
2010-08-13 14:18:10 +02:00
// for qml debugging
QString qmlServerAddress;
quint16 qmlServerPort;
QML Debugger: Mangle shadow build filenames Without doing some magic for the filenames, we go to shadow build files instead of the real ones, resulting in confusion. The user should never see the shadow build files while debugging. Reviewed-by: hjk
2010-09-08 13:31:12 +02:00
QString projectBuildDir;
QString projectDir;
// for cpp+qml debugging
DebuggerEngineType cppEngineType;
QML Debugger refactoring Now, QmlEngine creates the connection to the inferior (debuggee), and notifies QmlInspector when a connection is established. Before, inspector created the debugger engin, which was wrong. QmlEngine's responsibilities are connecting to the debuggee and basic QML/JS debugging features like locals & watchers, breakpoints etc. QmlInspector takes care of Live Preview and other fancy inspection features. Reviewed-by: hjk
2010-08-13 14:18:10 +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
// for remote debugging
QString remoteChannel;
QString remoteArchitecture;
Debugger/Remote Debugging: Add "GNU target" start parameter. This is needed for multi-architecture gdb. Reviewed-by: hjk
2010-10-29 14:04:23 +02:00
QString gnuTarget;
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
QString symbolFileName;
debugger: fix remote adapter startup
2010-09-06 11:33:07 +02:00
bool useServerStartScript;
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
QString serverStartScript;
QString sysRoot;
Maemo: Complete support for debugging via remote gdb. 1) Make sources available on device. 2) Enable users to switch between gdb and gdbserver approach (users may not be able to use the former if they have no control over their firewall). Reviewed-by: kh1
2010-07-30 12:14:54 +02:00
QByteArray remoteDumperLib;
QByteArray remoteSourcesDir;
Debugger/GDB: Map remote to local source file names. Necessary for debugging with a remote gdb (as opposed to gdbserver). Reviewed-by: kh1
2010-08-09 15:27:21 +02:00
QString remoteMountPoint;
QString localMountDir;
Maemo: Complete support for debugging via remote gdb. 1) Make sources available on device. 2) Enable users to switch between gdb and gdbserver approach (users may not be able to use the former if they have no control over their firewall). Reviewed-by: kh1
2010-07-30 12:14:54 +02:00
Core::SshConnectionParameters connParams;
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
QString debuggerCommand;
int toolChainType;
QString qtInstallPath;
QString dumperLibrary;
QStringList dumperLibraryLocations;
DebuggerStartMode startMode;
Executable's UID added to the DebuggerStartParameters. Used for debugging on SymbianOs
2010-08-20 12:58:37 +02:00
// for SymbianOS debugging
quint32 executableUid;
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: 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 DisassemblerViewAgent;
class MemoryViewAgent;
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: 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: 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: 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
explicit DebuggerEngine(const DebuggerStartParameters &sp);
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: 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 setToolTipExpression(const QPoint & mousePos,
debugger: kill command handler & company
2010-11-08 15:19:13 +01:00
TextEditor::ITextEditor *editor, int cursorPos);
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: 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
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 &);
virtual void fetchMemory(Internal::MemoryViewAgent *, QObject *,
quint64 addr, quint64 length);
virtual void fetchDisassembler(Internal::DisassemblerViewAgent *);
virtual void activateFrame(int index);
virtual void reloadModules();
virtual void examineModules();
virtual void loadSymbols(const QString &moduleName);
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;
virtual unsigned debuggerCapabilities() 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 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
Asynchronous breakpoint handling
2010-11-08 18:55:32 +01:00
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();
virtual bool acceptsBreakpoint(BreakpointId id) const; // FIXME: make pure
virtual void insertBreakpoint(BreakpointId id); // FIXME: make pure
virtual void removeBreakpoint(BreakpointId id); // FIXME: make pure
virtual void changeBreakpoint(BreakpointId id); // FIXME: make pure
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
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: suppress variable tooltips with outdated contents
2010-09-15 19:02:12 +02:00
virtual void removeTooltip();
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: refactor startup logic
2010-07-08 18:10:50 +02:00
protected:
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
friend class Internal::DebuggerPluginPrivate;
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 detachDebugger();
debugger: rename 'stop/quit' to exitDebugger
2010-11-08 17:43:31 +01:00
virtual void exitDebugger();
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 executeStep();
virtual void executeStepOut() ;
virtual void executeNext();
virtual void executeStepI();
virtual void executeNextI();
virtual void executeReturn();
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 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 continueInferior();
virtual void interruptInferior();
debugger: re-enable setting breakpoints while inferior is running
2010-07-20 12:14:59 +02:00
virtual void requestInterruptInferior();
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 executeRunToLine(const QString &fileName, int lineNumber);
virtual void executeRunToFunction(const QString &functionName);
virtual void executeJumpToLine(const QString &fileName, int lineNumber);
virtual void executeDebuggerCommand(const QString &command);
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 void frameUp();
virtual void frameDown();
public:
const DebuggerStartParameters &startParameters() const;
DebuggerStartParameters &startParameters();
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
Internal::ModulesHandler *modulesHandler() const;
Internal::RegisterHandler *registerHandler() const;
Internal::StackHandler *stackHandler() const;
Internal::ThreadsHandler *threadsHandler() const;
Internal::WatchHandler *watchHandler() const;
Internal::SourceFilesHandler *sourceFilesHandler() const;
debugger: move logical ownership of breakhandler from engines to plugin
2010-11-04 09:54:23 +01:00
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;
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);
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
void showModuleSymbols(const QString &moduleName, const Internal::Symbols &symbols);
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
void breakByFunction(const QString &functionName);
void breakByFunctionMain();
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: move BreakpointData into file of its own
2010-07-13 17:16:31 +02:00
bool isActive() const; // True if this is the currently active engine;
void setActive(bool on); // FIXME: private?
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
Fix CDB/trkgdbadapter.
2010-07-14 16:01:53 +02:00
Q_SLOT void showMessage(const QString &msg, int channel = LogDebug, int timeout = -1) const;
Q_SLOT void showStatusMessage(const QString &msg, int timeout = -1) const;
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +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
void resetLocation();
QML Debugger: Mangle shadow build filenames Without doing some magic for the filenames, we go to shadow build files instead of the real ones, resulting in confusion. The user should never see the shadow build files while debugging. Reviewed-by: hjk
2010-09-08 13:31:12 +02:00
virtual void gotoLocation(const QString &fileName, int lineNumber, bool setMarker);
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 gotoLocation(const Internal::StackFrame &frame, bool setMarker);
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: 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: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +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
signals:
void stateChanged(const DebuggerState &state);
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +02:00
void updateViewsRequested();
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 notifyInferiorIll();
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: code cosmetics
2010-07-08 15:06:09 +02:00
void setState(DebuggerState state, bool forced = false);
debugger: rename m_runInWrapperEngine into m_isSlaveEngine
2010-10-27 14:25:36 +02:00
void setSlaveEngine(bool value);
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
qml debugger: make the application output work
2010-08-25 16:48:35 +02:00
protected:
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
DebuggerRunControl *runControl() const;
debugger: code cosmetics
2010-07-08 15:06:09 +02:00
debugger: work on action handling
2010-06-22 17:18:29 +02:00
private:
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
// wrapper engine needs access to state of its subengines
friend class QmlCppEngine;
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
#endif // DEBUGGER_DEBUGGERENGINE_H
Copy Permalink