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

361 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;
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;
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
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
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;
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;
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 {
class DisassemblerViewAgent;
class MemoryViewAgent;
class Symbol;
class WatchData;
class BreakHandler;
class ModulesHandler;
class RegisterHandler;
class StackHandler;
class StackFrame;
class SourceFilesHandler;
class ThreadsHandler;
class WatchHandler;
QmlObserver: breakpoint list is shared between engines Reviewed by: Kai Koehne, Andre Poenitz
2010-10-05 11:01:14 +02:00
class BreakpointData;
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: 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: 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,
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
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 bool isSessionEngine() const;
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
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 attemptBreakpointSynchronization();
QmlObserver: breakpoint list is shared between engines Reviewed by: Kai Koehne, Andre Poenitz
2010-10-05 11:01:14 +02:00
virtual bool acceptsBreakpoint(const Internal::BreakpointData *);
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 selectThread(int index);
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Fixes around watch editing. assignValueInDebugger: Pass on WatchData as well, pass on values as QVariant. Based on that, do more extensive checks in CDB, preventing assignment of non-PODs. Locals/Watch editing: * Disable while running * Edit pointer values as hex with validation. CDB: Strip class types off reported pointer values and reformat the values as short 0x-pointer values, introduce flag to WatchData::source to do dumper expansion handling. Windows: recognize int64 as int. Register handler: Fix accessing uninitialized value.
2010-09-23 13:22:08 +02:00
virtual void assignValueInDebugger(const Internal::WatchData *w, 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 startup logic
2010-07-08 18:10:50 +02:00
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: 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();
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: 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: 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:
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();
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::BreakHandler *breakHandler() const;
Internal::RegisterHandler *registerHandler() const;
Internal::StackHandler *stackHandler() const;
Internal::ThreadsHandler *threadsHandler() const;
Internal::WatchHandler *watchHandler() const;
Internal::SourceFilesHandler *sourceFilesHandler() 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 *commandModel() const;
virtual QAbstractItemModel *modulesModel() const;
virtual QAbstractItemModel *breakModel() 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;
debuygger: make snapshots using true parallel engines
2010-07-13 15:57:34 +02:00
//QAbstractItemModel *snapshotModel() 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);
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();
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;
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();
void openFile(const QString &fileName, int lineNumber = -1);
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();
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);
bool isSlaveEngine() 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
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:
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
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