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

338 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'
#include <coreplugin/ssh/sshconnection.h>
#include <QtCore/QObject>
#include <QtCore/QSharedPointer>
#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 {
class DebuggerRunControl;
class DebuggerPlugin;
class DEBUGGER_EXPORT DebuggerStartParameters
{
public:
DebuggerStartParameters();
void clear();
QString executable;
QString displayName;
QString coreFile;
QStringList processArgs;
QStringList environment;
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;
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;
QString symbolFileName;
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 {
class DisassemblerViewAgent;
class MemoryViewAgent;
class Symbol;
class WatchData;
class BreakHandler;
class ModulesHandler;
class RegisterHandler;
class StackHandler;
class StackFrame;
class SourceFilesHandler;
class ThreadsHandler;
class WatchHandler;
class DebuggerEnginePrivate;
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:
DebuggerEngine(const DebuggerStartParameters &sp);
virtual ~DebuggerEngine();
Compile Windows.
2010-06-22 12:28:05 +02:00
virtual void setToolTipExpression(const QPoint & /* mousePos */,
TextEditor::ITextEditor * /* editor */, int /* cursorPos */) { }
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 initializeFromTemplate(DebuggerEngine *other);
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
virtual void updateWatchData(const WatchData & /* data */) { }
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: refactor startup logic
2010-07-08 18:10:50 +02:00
virtual bool isSessionEngine() const { return false; }
virtual void watchPoint(const QPoint &) {}
virtual void fetchMemory(MemoryViewAgent *, QObject *,
quint64 addr, quint64 length);
virtual void fetchDisassembler(DisassemblerViewAgent *) {}
virtual void activateFrame(int index) { Q_UNUSED(index); }
virtual void reloadModules() {}
debugger: start attempt to handle dwarf index data
2010-07-22 16:53:01 +02:00
virtual void examineModules() {}
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
virtual void loadSymbols(const QString &moduleName)
{ Q_UNUSED(moduleName); }
virtual void loadAllSymbols() {}
virtual void requestModuleSymbols(const QString &moduleName)
{ Q_UNUSED(moduleName); }
virtual void reloadRegisters() {}
virtual void reloadSourceFiles() {}
virtual void reloadFullStack() {}
virtual void setRegisterValue(int regnr, const QString &value);
virtual void addOptionPages(QList<Core::IOptionsPage*> *) const {}
virtual unsigned debuggerCapabilities() const { return 0; }
virtual bool isSynchroneous() const { return false; }
virtual QString qtNamespace() const { return QString(); }
debugger: re-enable snapshot creation using the menu action
2010-07-21 09:42:33 +02:00
virtual void createSnapshot() {}
debuygger: make snapshots using true parallel engines
2010-07-13 15:57:34 +02:00
virtual void updateAll() {}
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
virtual void attemptBreakpointSynchronization() {}
virtual void selectThread(int index) { Q_UNUSED(index); }
virtual void assignValueInDebugger(const QString &expr, const QString &value)
{ Q_UNUSED(expr); Q_UNUSED(value); }
debugger: move convienience function to DebuggerEngine base class
2010-07-21 14:24:29 +02:00
// Convenience
static QMessageBox *showMessageBox
(int icon, const QString &title, const QString &text, int buttons = 0);
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
protected:
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 detachDebugger() {}
virtual void executeStep() {}
virtual void executeStepOut() {}
virtual void executeNext() {}
virtual void executeStepI() {}
virtual void executeNextI() {}
virtual void executeReturn() {}
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: 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 executeRunToLine(const QString &fileName, int lineNumber)
{ Q_UNUSED(fileName); Q_UNUSED(lineNumber); }
virtual void executeRunToFunction(const QString &functionName)
{ Q_UNUSED(functionName); }
virtual void executeJumpToLine(const QString &fileName, int lineNumber)
{ Q_UNUSED(fileName); Q_UNUSED(lineNumber); }
virtual void executeDebuggerCommand(const QString &command)
{ Q_UNUSED(command); }
virtual void frameUp();
virtual void frameDown();
public:
debugger: move convienience function to DebuggerEngine base class
2010-07-21 14:24:29 +02:00
static DebuggerPlugin *plugin();
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
const DebuggerStartParameters &startParameters() const;
DebuggerStartParameters &startParameters();
ModulesHandler *modulesHandler() const;
BreakHandler *breakHandler() const;
RegisterHandler *registerHandler() const;
StackHandler *stackHandler() const;
ThreadsHandler *threadsHandler() const;
WatchHandler *watchHandler() const;
SourceFilesHandler *sourceFilesHandler() const;
QAbstractItemModel *commandModel() const;
QAbstractItemModel *modulesModel() const;
QAbstractItemModel *breakModel() const;
QAbstractItemModel *registerModel() const;
QAbstractItemModel *stackModel() const;
QAbstractItemModel *threadsModel() const;
QAbstractItemModel *localsModel() const;
QAbstractItemModel *watchersModel() const;
QAbstractItemModel *returnModel() const;
debuygger: make snapshots using true parallel engines
2010-07-13 15:57:34 +02:00
//QAbstractItemModel *snapshotModel() 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
QAbstractItemModel *sourceFilesModel() const;
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);
void showModuleSymbols(const QString &moduleName, const Symbols &symbols);
void breakByFunction(const QString &functionName);
void breakByFunctionMain();
void executeStepX();
void executeStepOutX();
void executeStepNextX();
void executeReturnX();
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;
bool isDying() const { return targetState() == DebuggerFinished; }
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();
void openFile(const QString &fileName, int lineNumber = -1);
void gotoLocation(const QString &fileName, int lineNumber, bool setMarker);
void gotoLocation(const 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
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: more state work
2010-07-13 08:41:27 +02:00
private:
debugger: code cosmetics
2010-07-08 15:06:09 +02:00
void setState(DebuggerState state, bool forced = false);
debugger: work on action handling
2010-06-22 17:18:29 +02:00
private:
void executeRunToLine();
void executeRunToFunction();
void executeJumpToLine();
debugger: fix addToWatchWindow
2010-06-22 18:30:18 +02:00
void addToWatchWindow();
debugger: work on action handling
2010-06-22 17:18:29 +02: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 Internal
} // namespace Debugger
#endif // DEBUGGER_DEBUGGERENGINE_H
Copy Permalink