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

595 lines
19 KiB
C
Raw Normal View History

Adjust license headers Change-Id: Ice592c6de9951ee3b2c4cb52ed0bb3b6770e0825 Reviewed-by: Eike Ziller <eike.ziller@digia.com>
2012-10-02 09:12:39 +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
**
Update License according to agreement with Free Qt Foundation * Update files in src/plugins Change-Id: Ia5d77fad7d19d4bb3498e78661982f68729adb22 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-01-15 14:57:40 +01:00
** Copyright (C) 2016 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
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
**
Adjust license headers Change-Id: Ice592c6de9951ee3b2c4cb52ed0bb3b6770e0825 Reviewed-by: Eike Ziller <eike.ziller@digia.com>
2012-10-02 09:12:39 +02:00
** This file is part of Qt Creator.
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
**
Adjust license headers Change-Id: Ice592c6de9951ee3b2c4cb52ed0bb3b6770e0825 Reviewed-by: Eike Ziller <eike.ziller@digia.com>
2012-10-02 09:12:39 +02:00
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
Update License according to agreement with Free Qt Foundation * Update files in src/plugins Change-Id: Ia5d77fad7d19d4bb3498e78661982f68729adb22 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-01-15 14:57:40 +01:00
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
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
**
Update License according to agreement with Free Qt Foundation * Update files in src/plugins Change-Id: Ia5d77fad7d19d4bb3498e78661982f68729adb22 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-01-15 14:57:40 +01:00
** GNU General Public License Usage
** Alternatively, this file may be used under the terms of the GNU
** General Public License version 3 as published by the Free Software
** Foundation with exceptions as appearing in the file LICENSE.GPL3-EXCEPT
** included in the packaging of this file. Please review the following
** information to ensure the GNU General Public License requirements will
** be met: https://www.gnu.org/licenses/gpl-3.0.html.
License headers.
2010-12-17 16:01:08 +01:00
**
Adjust license headers Change-Id: Ice592c6de9951ee3b2c4cb52ed0bb3b6770e0825 Reviewed-by: Eike Ziller <eike.ziller@digia.com>
2012-10-02 09:12:39 +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
Wholesale conversion to #pragma once Kudos to cgmb and https://github.com/cgmb/guardonce Change-Id: Ifa8970734b8d43fd08c9260c645bdb0228633791 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2016-03-18 07:55:01 +01:00
#pragma once
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 "debugger_global.h"
#include "debuggerconstants.h"
Debugger: Use a StandardRunnable for the debugger process One step further to separate the debugger environment from the inferior environment and to make it possible to configure a working directory. Guessing one from the inferior's working directory is not always a good idea. Change-Id: I33d139c0f228ec0870556b82bc6aecca0a8e62d6 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-07-29 15:55:15 +02:00
#include "debuggeritem.h"
Debugger: Make DebuggerEngine::runCommand() virtual. Allows default implementation of e.g. stack retrieval in the base class. Change-Id: I96460b19aa31347b2c863736b4ce2b5046eb4de6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-11-03 12:01:57 +01:00
#include "debuggerprotocol.h"
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
#include "breakhandler.h"
Debugger: Streamline ThreadHandler - Use the TreeItem/data pattern recently introduced with Breakpoints to remove the need of keeping track of id/object mapping. Opens possibility to have thread groups as intermediate level. - Use the ThreadHandler directly as model for the thread combobox to remove the need of manual combo box updates. - Move setting current thread from individual engines to central code. Change-Id: I030e21a4aa5ab30b0efbc84528d9cecf29cbbe30 Reviewed-by: David Schulz <david.schulz@qt.io>
2018-08-15 17:28:00 +02:00
#include "threadshandler.h"
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
#include <coreplugin/icontext.h>
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
#include <projectexplorer/devicesupport/idevice.h>
ProjectExplorer: Move RunControl related classes to separate file pair Change-Id: I5da56f80336673d595907abcc797f628be680cd5 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-03-13 08:06:08 +01:00
#include <projectexplorer/runcontrol.h>
Debugger: Restrict LocationMark dragging ... to engines that actually support JumpToLine and make it work in disassembler views. Change-Id: I10368ea719587caa7c4f33665eff57c2bf300d84 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-17 16:33:25 +02:00
#include <texteditor/textmark.h>
FileInProjectFinder: Use FileNameList for file names This simplifies code and reduces the number of conversions between QString and Utils::FileName. Change-Id: I47bd86b9ae09b1da37b4e5e604761367ac1ab26b Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
2018-05-24 11:17:04 +02:00
#include <utils/fileutils.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
Debugger: Merge GDB/LLDB process error handling This also removes some of the "illegal" state transitions, partially addressing QTCREATORBUG-14089. Change-Id: I817d87a0b5e0a40285bc9b0880fef5bceaee3f16 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-03-05 11:11:32 +01:00
#include <QProcess>
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_BEGIN_NAMESPACE
class QDebug;
class QPoint;
QT_END_NAMESPACE
debugger: parse build-id-verbose output into tasks Change-Id: I6bacc697c24185025f3342e43a29109bf75d8196 Reviewed-by: hjk <qthjk@ovi.com>
2012-03-30 17:36:44 +02:00
namespace Core { class IOptionsPage; }
Debugger: Use ProcessHandle in notifyInferiorPid() Change-Id: Idcb6819b64964b6aa0e72d182cc628feba37ba55 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-03-01 09:35:28 +01:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
namespace Utils {
class MacroExpander;
class Perspective;
} // Utils
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
namespace Debugger {
Debugger: Make DebuggerRunTool publicly accessible That's a temporary move to be able to port the per-target Debug*Support classes one by one. Change-Id: I3cf5f9ea367a68058add8713ed23f44da080a175 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-04-21 10:10:25 +02:00
class DebuggerRunTool;
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: Code cosmetics Move some constants to internalconstants.h or remove them entirely. Change-Id: Iecd4def3b48130fb390bddf420da672d44e3d6b8 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2019-02-18 15:49:05 +01:00
enum DebuggerState
{
DebuggerNotReady, // Debugger not started
EngineSetupRequested, // Engine starts
EngineSetupFailed,
EngineRunRequested,
EngineRunFailed,
InferiorUnrunnable, // Used in the core dump adapter
InferiorRunRequested, // Debuggee requested to run
InferiorRunOk, // Debuggee running
InferiorRunFailed, // Debuggee not running
InferiorStopRequested, // Debuggee running, stop requested
InferiorStopOk, // Debuggee stopped
InferiorStopFailed, // Debuggee not stopped, will kill debugger
InferiorShutdownRequested,
InferiorShutdownFinished,
EngineShutdownRequested,
EngineShutdownFinished,
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
DEBUGGER_EXPORT QDebug operator<<(QDebug str, DebuggerState state);
namespace Internal {
Debugger: Make DebuggerEngine internal Expose less of debugger internals to the device plugins. Change-Id: Ie78756b033fae3fe02bff92eadf26b7319990605 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com> Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-12 15:33:16 +01:00
class DebuggerEnginePrivate;
debugger: refactoring of the plugin interface There's some 'external' and some 'internal' part now. Other plugins are only supposed the external interface.
2010-11-10 11:39:01 +01:00
class DebuggerPluginPrivate;
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
class DisassemblerAgent;
class MemoryAgent;
Debugger: Remove most remaining occurrences of WatchData ... in WatchHandler and DebuggerEngine interface. Adjust using code. Change-Id: I6371f3e96ba46a783e23a5767cdde24a10d3fce7 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-03-19 12:42:53 +01:00
class WatchItem;
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 BreakHandler;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
class BreakpointParameters;
Debugger: Make LocationMark draggable Issue a DebuggerEngine::executeJumpToLine() in response. Change-Id: I7be5738241ce91f61002d6f6b49c796824569024 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-16 08:14:17 +02:00
class LocationMark;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
class LogWindow;
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 ModulesHandler;
class RegisterHandler;
Debugger: Add peripheral registers description file support This feature is useful for the bare-metal programming. It allows to view the peripheral registers of the debugged device using the GDB. An information about the peripheral registers for a concrete device contains in a special SVD file. A format of this file described e.g. here: * https://www.keil.com/pack/doc/CMSIS/SVD/html/svd_Format_pg.html This feature supported only for ARM devices, and an appropriate SVD files can be found in the Internet, also this files provides by KEIL or IAR EW IDE's. A use case in QtC is that the user should to choose desired SVD file and set its path to the bare-metal device configuration widget. After this, the user can enable the "Peripheral Registers" view, choose a desired register group and to see a peripheral register values. Currently the following basic features are implemented: * Choosing SVD file for a target bare-metal device. * Choosing any peripheral register group, which is available for this device. * Seeing the info about the each peripheral register and its fields. * Seeing the value for the each peripheral register and its fields. * Changing the value for the each peripheral register and its fields (if it is allowed by access for a concrete register or field). * Changing the format of the values (hexadecimal, decimal, octal, binary). Fixes: QTCREATORBUG-18729 Change-Id: I3c38ea50ccd2e128746458f9b918095b4c2d644a Reviewed-by: hjk <hjk@qt.io>
2019-07-28 23:32:33 +03:00
class PeripheralRegisterHandler;
Debugger: Move showModule{Sections,Symbols} to DebuggerEngine A bit closer to where the functions are used. No real change. Change-Id: Icbad68bd31d85caa59980316537ee532faf2d7ef Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2019-09-19 16:36:43 +02:00
class Section;
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 SourceFilesHandler;
Debugger: Move showModule{Sections,Symbols} to DebuggerEngine A bit closer to where the functions are used. No real change. Change-Id: Icbad68bd31d85caa59980316537ee532faf2d7ef Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2019-09-19 16:36:43 +02:00
class StackFrame;
class StackHandler;
class Symbol;
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 WatchHandler;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
class WatchTreeView;
Debugger: Make tooltips pinnable. Replace old debugger tooltip by a new ToolTipManager which has a list of AbstractDebuggerToolTipWidget with the functionality to 'acquire' an engine (display its data) and 'release' it (store engine data and display them as 'previous') and serialization to XML session data. DebuggerTreeViewToolTipWidget implements AbstractDebuggerToolTipWidget for tree model acting as a filter on watch models. Rubber-stamped-by: hjk
2011-02-11 15:00:13 +01:00
class DebuggerToolTipContext;
Debugger: Split ToolTipManager into per-engine parts Change-Id: If2e601a91ad2a0e5ba30916a5d1f2312ecff944f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-23 15:21:43 +02:00
class DebuggerToolTipManager;
Debugger: Rework register handling Use register names as handle, not their index in the view. Store the raw real values, not some stringified version as primary data. Use subentries to break down bigger registers into smaller entities. Also remember the previous value of a register and show it in a tooltip. Change-Id: I8ae3cc8766a7b211bc7cc827c734e5cf6060825c Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-17 13:14:29 +01:00
class MemoryViewSetupData;
Debugger: Move external terminal into separate RunWorker Change-Id: Ifb9701f840195ba90db48a0f6fa07b28e0409648 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-27 08:22:02 +02:00
class TerminalRunner;
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: Merge DebuggerStartParameter into *RunParameters The users (typically target specific DebuggerRunTool derived classes) are meant to use the individual setter functions nowadays, not the set up the full structure, so the members are a true implementation detail now. Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:53:56 +02:00
class DebuggerRunParameters
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
{
public:
Debugger: Merge DebuggerStartParameter into *RunParameters The users (typically target specific DebuggerRunTool derived classes) are meant to use the individual setter functions nowadays, not the set up the full structure, so the members are a true implementation detail now. Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:53:56 +02:00
DebuggerStartMode startMode = NoStartMode;
DebuggerCloseMode closeMode = KillAtClose;
Finish merging Runnable and StandardRunnable As all Runnables are known to be StandardRunnables, this here essentially replaces all .is<StandardRunnable> by 'true'. .as<StandardRunnable> by no-op, and fixes the fallout. Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2018-05-16 15:42:03 +02:00
ProjectExplorer::Runnable inferior;
Debugger: Merge DebuggerStartParameter into *RunParameters The users (typically target specific DebuggerRunTool derived classes) are meant to use the individual setter functions nowadays, not the set up the full structure, so the members are a true implementation detail now. Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:53:56 +02:00
QString displayName; // Used in the Snapshots view.
Utils::ProcessHandle attachPID;
QStringList solibSearchPath;
// Used by Qml debugging.
QUrl qmlServer;
// Used by general remote debugging.
QString remoteChannel;
bool useExtendedRemote = false; // Whether to use GDB's target extended-remote or not.
ProjectExplorer: Use Utils::FileName for Runnable::executable Change-Id: I584bc18aa19a4c9886af7b13e95052dfd4350b34 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2019-06-20 17:19:12 +02:00
Utils::FilePath symbolFile;
Debugger: Merge DebuggerStartParameter into *RunParameters The users (typically target specific DebuggerRunTool derived classes) are meant to use the individual setter functions nowadays, not the set up the full structure, so the members are a true implementation detail now. Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:53:56 +02:00
// Used by Mer plugin (3rd party)
QMap<QString, QString> sourcePathMap;
// Used by baremetal plugin
QString commandsForReset; // commands used for resetting the inferior
bool useContinueInsteadOfRun = false; // if connected to a hw debugger run is not possible but continue is used
QString commandsAfterConnect; // additional commands to post after connection to debug target
// Used by Valgrind
QStringList expectedSignals;
// For QNX debugging
bool useCtrlCStub = false;
// Used by Android to avoid false positives on warnOnRelease
bool skipExecutableValidation = false;
bool useTargetAsync = false;
Utils: Rename FilePathList to simply FilePaths The exact storage type does not really matter here. Change-Id: Iefec40f0f5909c8e7ba3415db4a11962694e1b38 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2019-12-17 14:07:53 +01:00
Utils::FilePaths additionalSearchDirectories;
Debugger: Merge DebuggerStartParameter into *RunParameters The users (typically target specific DebuggerRunTool derived classes) are meant to use the individual setter functions nowadays, not the set up the full structure, so the members are a true implementation detail now. Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:53:56 +02:00
// Used by iOS.
QString platform;
QString deviceSymbolsRoot;
bool continueAfterAttach = false;
Utils: Rename FileName to FilePath More in line with QFileInfo terminonlogy which appears to be best-of-breed within Qt. Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-28 13:49:26 +02:00
Utils::FilePath sysRoot;
Debugger: Merge DebuggerStartParameter into *RunParameters The users (typically target specific DebuggerRunTool derived classes) are meant to use the individual setter functions nowadays, not the set up the full structure, so the members are a true implementation detail now. Change-Id: Ida04801e3230a2fe8bbadde8845e58c3077c87a5 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:53:56 +02:00
// Used by general core file debugging. Public access requested in QTCREATORBUG-17158.
QString coreFile;
// Macro-expanded and passed to debugger startup.
QString additionalStartupCommands;
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
Debugger: Continue DebuggerStartParameter cleanup - Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters, they are always the one coming from the kit. - Move projectSource{Directory,Files} to DebuggerRunParameters, they are alway coming from the runConfiguration's project - Pass RunConfiguration always as separate parameter, that's what related code does. Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
2015-06-26 13:06:08 +02:00
DebuggerEngineType cppEngineType = NoEngineType;
Debugger: Replace RunParameter::languagues by individual bools There was almost 1:1 overlap with DebuggerRunTool::is{Cpp,Qml}Debugging, use one version only. Change-Id: I4a8f2b7005d3f2e440cdab3eaf6ac476af894308 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-20 16:34:54 +02:00
bool isQmlDebugging = false;
Debugger: Continue DebuggerStartParameter cleanup - Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters, they are always the one coming from the kit. - Move projectSource{Directory,Files} to DebuggerRunParameters, they are alway coming from the runConfiguration's project - Pass RunConfiguration always as separate parameter, that's what related code does. Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
2015-06-26 13:06:08 +02:00
bool breakOnMain = false;
bool multiProcess = false; // Whether to set detach-on-fork off.
Remove ApplicationLauncher::Mode The actual remaining use was to pop up a terminal in some setups where Mode == Console, with a default of Gui meaning "no console". In some downstream uses it was used set to Console (probably to mean "this helper process does not need a gui") but then luckily ignored when actually starting the helper processes. All cases where the console is useful and requested are nowadays RunWorkers belonging to RunConfigurations with a TerminalAspect, so they can directly get the relevant bit from their RunConfiguration without having it part of all StandardRunnables. Change-Id: I1368d5968da5cf672656aebf200ccac8d45335d0 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-05-03 18:15:49 +02:00
bool useTerminal = false;
ProjectExplorer/Debugger: Add a 'Run as root' option for Unix hosts For local run and GDB debug, with or without terminal. Task-number: QTCREATORBUG-2831 Task-number: QTCREATORBUG-25330 Change-Id: I9b5d2156bcffea4f358474ecdbcad580a4419917 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2021-02-15 16:55:28 +01:00
bool runAsRoot = false;
Debugger: Continue DebuggerStartParameter cleanup - Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters, they are always the one coming from the kit. - Move projectSource{Directory,Files} to DebuggerRunParameters, they are alway coming from the runConfiguration's project - Pass RunConfiguration always as separate parameter, that's what related code does. Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
2015-06-26 13:06:08 +02:00
Finish merging Runnable and StandardRunnable As all Runnables are known to be StandardRunnables, this here essentially replaces all .is<StandardRunnable> by 'true'. .as<StandardRunnable> by no-op, and fixes the fallout. Change-Id: I1632f8e164fa0a9dff063df47a9e191fdf7bbb2e Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2018-05-16 15:42:03 +02:00
ProjectExplorer::Runnable debugger;
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
QString overrideStartScript; // Used in attach to core and remote debugging
QString startMessage; // First status message shown.
QString debugInfoLocation; // Gdb "set-debug-file-directory".
QStringList debugSourceLocation; // Gdb "directory"
Debugger: automatically add source path mapping for Qt packages Change-Id: I1199629729e3996adb574089c5db69f1fcf0ccd0 Reviewed-by: hjk <hjk@qt.io>
2017-12-08 13:55:15 +01:00
QString qtPackageSourceLocation;
Debugger: Rework start parameter completion. It's again a linear process now, with explicit entrance point for all users. Task-number: QTCREATORBUG-14618 Change-Id: I96c08947270ce34d7bc6c8be1d7f350dbfa14794 Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com> Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-24 08:26:35 +02:00
bool isSnapshot = false; // Set if created internally.
Debugger: Continue DebuggerStartParameter cleanup - Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters, they are always the one coming from the kit. - Move projectSource{Directory,Files} to DebuggerRunParameters, they are alway coming from the runConfiguration's project - Pass RunConfiguration always as separate parameter, that's what related code does. Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
2015-06-26 13:06:08 +02:00
ProjectExplorer::Abi toolChainAbi;
Utils: Rename FileName to FilePath More in line with QFileInfo terminonlogy which appears to be best-of-breed within Qt. Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-28 13:49:26 +02:00
Utils::FilePath projectSourceDirectory;
Utils: Rename FilePathList to simply FilePaths The exact storage type does not really matter here. Change-Id: Iefec40f0f5909c8e7ba3415db4a11962694e1b38 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2019-12-17 14:07:53 +01:00
Utils::FilePaths projectSourceFiles;
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
Debugger: Rework Python Debugger The (re-)enables basic stepping, data display, frame selection etc for Python 2 and 3. Arguments passing, jump to line etc. don't work yet. Change-Id: I8af03e5905092360eb268ba3081a1236b1f8577f Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-23 11:23:52 +02:00
// Used by Script debugging
QString interpreter;
QString mainScript;
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
// Used by AttachCrashedExternal.
QString crashParameter;
Debugger: Infrastructure for reworked native mixed debugging - Remove old experimental native mixed approach. - Move some common stack parsing to Stackhandler. - Mark gdbbridge.py debug output explicitly to remove it from actual reponse handling New native mixed needs QtDeclarative changes and QTC_DEBUGGER_NATIVE_MIXED=1 for now. Change-Id: I09eed1da51cea878636d36756015b7bfaed34203 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-10-08 16:19:57 +02:00
bool nativeMixedEnabled = false;
Debugger: remove redundant info whether to use cpp debugging Task-number: QTCREATORBUG-20168 Change-Id: I2a0bfba6aea39da443032fd9ab02869cdc508696 Reviewed-by: hjk <hjk@qt.io>
2018-07-25 14:07:08 +02:00
bool isCppDebugging() const;
Debugger: Remove non-const access to RunParameters The idea is that they shouldn't change after start() to be re-usable for an additional run later. Change-Id: I272fc975657b0d8b5b13a07d58bd0b626868d32e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-19 17:36:12 +02:00
bool isNativeMixedDebugging() const;
Debugger: Modernize Mostly nullptr instead of 0, but also a few bits of collateral damage. Change-Id: I921991272aca921dcdecf302dfff3716e79dfc24 Reviewed-by: David Schulz <david.schulz@qt.io>
2018-02-01 10:59:24 +01:00
Utils::MacroExpander *macroExpander = nullptr;
Debugger: Use kit macro expander instead of global one where possible This is low hanging fruit enabling a lot more customization. Change-Id: I1a90fa731ea512852c12a55fad75551efb44e875 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-03-22 10:47:03 +01:00
Debugger: Add more information about the debugee when debugging Fixes: QTCREATORBUG-25159 Change-Id: Ic462c8bb4d9f4f7163dbb9fcc13adce4c7172564 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: André Hartmann <aha_1980@gmx.de>
2021-03-15 15:14:08 +01:00
Utils::optional<int> exitCode = {};
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
// For Debugger testing.
Debugger: Rework start parameter completion. It's again a linear process now, with explicit entrance point for all users. Task-number: QTCREATORBUG-14618 Change-Id: I96c08947270ce34d7bc6c8be1d7f350dbfa14794 Reviewed-by: Kai Koehne <kai.koehne@theqtcompany.com> Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-24 08:26:35 +02:00
int testCase = 0;
Debugger: Remove parts of the engine parameter fixup phase The idea is that the fixup should not be needed at all anymore, instead, static data coming e.g. from the RunConfiguration should be setup in the constructor, and everything else should be ready at entry into start(). This also proceeds on path to the planned-but-never-implemented idea that the RunConfiguration should (at most) be accessed at RunControl creation time, not later. Change-Id: I04d622785f5de628a7bb479bc0c39aff7d6cce01 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-18 14:47:39 +02:00
QStringList validationErrors;
Debugger: Split off runtime-only items from DebuggerStartParameters Right now, DebuggerStartParameter is part of the debugger plugin external interface. Better not make it fatter than necessary. Change-Id: I3b9205089f971dd314ccba1335b5ca2d4d9fe7c6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-05-27 13:59:56 +02:00
};
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
class UpdateParameters
{
public:
Debugger: Don't clear unrelated views when updating locals If the list of partial expressions is empty we need to tell the watch handler that we are only updating the locals view, not e.g. the inspector view. Change-Id: Iedc74ffc66a8435faa272d053849b831f6b8cbbe Task-number: QTCREATORBUG-16692 Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: hjk <hjk@qt.io>
2016-11-03 13:28:28 +01:00
UpdateParameters(const QString &partialVariable = QString()) :
partialVariable(partialVariable) {}
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
QStringList partialVariables() const
Debugger: Simplify removal of outdated L&E items This removes the need of bookkeeping on the engine side. It's basically a kind of mark-and-sweep: On update begin mark items that are expected to change as outdated, while data arrives, undo that marking, and update end remove all remaining marked items. Change-Id: I739b84869033d511d5c9a80605c079e87ef4f6a7 Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-07-06 09:46:08 +02:00
{
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
QStringList result;
Debugger: Simplify removal of outdated L&E items This removes the need of bookkeeping on the engine side. It's basically a kind of mark-and-sweep: On update begin mark items that are expected to change as outdated, while data arrives, undo that marking, and update end remove all remaining marked items. Change-Id: I739b84869033d511d5c9a80605c079e87ef4f6a7 Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-07-06 09:46:08 +02:00
if (!partialVariable.isEmpty())
result.append(partialVariable);
return result;
}
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
QString partialVariable;
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
};
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
class Location
{
public:
Debugger: Modernize modernize-use-auto modernize-use-nullptr modernize-use-override modernize-use-using modernize-use-default-member-init modernize-use-equals-default Change-Id: I91a6874f0d7b94e9079ab4ef07c23c60c80be9c0 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-23 22:28:49 +02:00
Location() = default;
Debugger: Drop Location::init() We can do better with C++11. Change-Id: Ie9e9cd4dfbbfc4ba29c0aa6bbfdf33ae7ac184fe Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-08-05 12:29:39 +02:00
Location(quint64 address) { m_address = address; }
Debugger: make Location::fileName a Utils::FilePath Change-Id: I637d39246ff576db1023f08c432a7f7b6aadbbaa Reviewed-by: hjk <hjk@qt.io>
2020-01-02 12:37:57 +01:00
Location(const Utils::FilePath &file) { m_fileName = file; }
Location(const Utils::FilePath &file, int line, bool marker = true)
Debugger: Drop Location::init() We can do better with C++11. Change-Id: Ie9e9cd4dfbbfc4ba29c0aa6bbfdf33ae7ac184fe Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-08-05 12:29:39 +02:00
{ m_lineNumber = line; m_fileName = file; m_needsMarker = marker; }
Debugger: Header cleanup
2011-01-10 10:14:23 +01:00
Location(const StackFrame &frame, bool marker = true);
Debugger: make Location::fileName a Utils::FilePath Change-Id: I637d39246ff576db1023f08c432a7f7b6aadbbaa Reviewed-by: hjk <hjk@qt.io>
2020-01-02 12:37:57 +01:00
Utils::FilePath fileName() const { return m_fileName; }
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
QString functionName() const { return m_functionName; }
Debugger[CDB]: Display more context in disassembly. Emulate gdb's behaviour trying to disassemble the function. Task-number: QTCREATORBUG-5205 Change-Id: I2f4dc9393e12324b0423734c5235758a25395fec Reviewed-on: http://codereview.qt.nokia.com/1029 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-07-04 09:29:28 +02:00
QString from() const { return m_from; }
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
int lineNumber() const { return m_lineNumber; }
void setNeedsRaise(bool on) { m_needsRaise = on; }
void setNeedsMarker(bool on) { m_needsMarker = on; }
Debugger: make Location::fileName a Utils::FilePath Change-Id: I637d39246ff576db1023f08c432a7f7b6aadbbaa Reviewed-by: hjk <hjk@qt.io>
2020-01-02 12:37:57 +01:00
void setFileName(const Utils::FilePath &fileName) { m_fileName = fileName; }
Debugger: Fall back to assembler in LLDB ... if source file does not exist. This is the same logic as for GDB now. Change-Id: I3e5a3273b571658b4dd4200c9b3a0e9542a16015 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-11-15 13:13:29 +01:00
void setUseAssembler(bool on) { m_hasDebugInfo = !on; }
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
bool needsRaise() const { return m_needsRaise; }
bool needsMarker() const { return m_needsMarker; }
bool hasDebugInfo() const { return m_hasDebugInfo; }
Debugger: Fix loading of Linux core files with LLDB Change-Id: I76183591c5242589c25d8e5695367d61b6cc5afc Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-02-27 11:56:03 +01:00
bool canBeDisassembled() const
{ return m_address != quint64(-1) || !m_functionName.isEmpty(); }
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
quint64 address() const { return m_address; }
private:
Debugger: Drop Location::init() We can do better with C++11. Change-Id: Ie9e9cd4dfbbfc4ba29c0aa6bbfdf33ae7ac184fe Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-08-05 12:29:39 +02:00
bool m_needsMarker = false;
bool m_needsRaise = true;
bool m_hasDebugInfo = true;
int m_lineNumber = -1;
Debugger: make Location::fileName a Utils::FilePath Change-Id: I637d39246ff576db1023f08c432a7f7b6aadbbaa Reviewed-by: hjk <hjk@qt.io>
2020-01-02 12:37:57 +01:00
Utils::FilePath m_fileName;
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
QString m_functionName;
Debugger[CDB]: Display more context in disassembly. Emulate gdb's behaviour trying to disassemble the function. Task-number: QTCREATORBUG-5205 Change-Id: I2f4dc9393e12324b0423734c5235758a25395fec Reviewed-on: http://codereview.qt.nokia.com/1029 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-07-04 09:29:28 +02:00
QString m_from;
Debugger: Drop Location::init() We can do better with C++11. Change-Id: Ie9e9cd4dfbbfc4ba29c0aa6bbfdf33ae7ac184fe Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-08-05 12:29:39 +02:00
quint64 m_address = 0;
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
};
Debugger: Make DebuggerEngine internal Expose less of debugger internals to the device plugins. Change-Id: Ie78756b033fae3fe02bff92eadf26b7319990605 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com> Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-12 15:33:16 +01:00
class 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: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
DebuggerEngine();
Debugger: Use override consistently clang-tidy fixes from modernize-use-override check. Change-Id: I6a20484716dc5bd84fe9592b40ae57be66fe32bf Reviewed-by: hjk <hjk@qt.io>
2018-05-07 15:06:53 +02:00
~DebuggerEngine() override;
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: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void setRunTool(DebuggerRunTool *runTool);
void setRunParameters(const DebuggerRunParameters &runParameters);
Debugger: Remove non-const access to RunParameters The idea is that they shouldn't change after start() to be re-usable for an additional run later. Change-Id: I272fc975657b0d8b5b13a07d58bd0b626868d32e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-19 17:36:12 +02:00
Debugger: Do not remember persistent layout settings per engine Fixes: QTCREATORBUG-21006 Change-Id: Id3c2062eb5b42808d666f0fc3620a82666fe14a2 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2018-09-04 13:29:15 +02:00
void setRunId(const QString &id);
QString runId() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
const DebuggerRunParameters &runParameters() const;
void setCompanionEngine(DebuggerEngine *engine);
void setSecondaryEngine();
Debugger: Move part of engine startup to preparation phase Change-Id: I414c356cd615096ee68588b839aaf975657fb7f9 Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2017-04-27 15:39:30 +02:00
void start();
Debugger: Move command flags to debugger command Also, remove the need to mark GDB Python commands, detect the need to use MI on the presence of non-Pythonic letters in the command (space and hyphen). Plan is to reuse even more almost shared code between engines. Change-Id: I4e00debb07f2482637930675a28f464666b59553 Reviewed-by: hjk <hjk@qt.io>
2016-12-13 13:37:05 +01:00
enum {
// Remove need to qualify each use.
NeedsTemporaryStop = DebuggerCommand::NeedsTemporaryStop,
NeedsFullStop = DebuggerCommand::NeedsFullStop,
Discardable = DebuggerCommand::Discardable,
ConsoleCommand = DebuggerCommand::ConsoleCommand,
NeedsFlush = DebuggerCommand::NeedsFlush,
ExitRequest = DebuggerCommand::ExitRequest,
RunRequest = DebuggerCommand::RunRequest,
LosesChild = DebuggerCommand::LosesChild,
InUpdateLocals = DebuggerCommand::InUpdateLocals,
Debugger: Allow explicitly marking of non-Python commands again This conceptually reverts part of a61b6dfc. Task-number: QTCREATORBUG-17594 Change-Id: I9ff72a027838a20039f217ed0d669b6c45bc2acf Reviewed-by: Eike Ziller <eike.ziller@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-01-20 10:05:31 +01:00
NativeCommand = DebuggerCommand::NativeCommand,
Debugger: Move command flags to debugger command Also, remove the need to mark GDB Python commands, detect the need to use MI on the presence of non-Pythonic letters in the command (space and hyphen). Plan is to reuse even more almost shared code between engines. Change-Id: I4e00debb07f2482637930675a28f464666b59553 Reviewed-by: hjk <hjk@qt.io>
2016-12-13 13:37:05 +01:00
Silent = DebuggerCommand::Silent
};
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
virtual bool canHandleToolTip(const DebuggerToolTipContext &) const;
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
virtual void expandItem(const QString &iname); // Called when item in tree gets expanded.
virtual void updateItem(const QString &iname); // Called for fresh watch items.
void updateWatchData(const QString &iname); // FIXME: Merge with above.
virtual void selectWatchData(const QString &iname);
Inspector: Update Editor on object selection When an object is selected in the Inspector, the Editor is updated to show the relevant code. Task-number: QTCREATORBUG-8246 Change-Id: I4f7fbcccdeb22849682fa72c63e87a78f48d185b Reviewed-by: hjk <qthjk@ovi.com> Reviewed-by: Christiaan Janssen <christiaan.janssen@digia.com>
2012-11-23 13:35:44 +01:00
Debugger: Make validateExecutable a validateRunParameters Gets rid of the odd and otherwise unused DebuggerEngine::mutableRunParameters() function. Change-Id: Ib0861432e7c61072db2968acf2f36c7f2d56c89a Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-11-13 09:20:24 +01:00
virtual void validateRunParameters(DebuggerRunParameters &) {}
Debugger: Clean up GdbEngine member data on finish Restarting with cached outdated information is problematic. Change-Id: I396da2fef96a161c1ab150134b8e65a758a16d58 Task-number: QTCREATORBUG-16355 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-05-27 13:57:21 +02:00
virtual void prepareForRestart() {}
Debugger: Move part of debugger ramp-down to DebuggerRunTool DebuggerRunTool and debugger backend process have (almost) a 1:1 correspondence, unlike engines or the debugger plugin itself. So it makes sense to accumulate backend start/rampdown login in DebuggerRunTool. Change-Id: Ia105283bcdf2641c7e9a401b4146b34c20605ba7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-05-25 17:33:20 +02:00
virtual void abortDebuggerProcess() {} // second attempt
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
Debugger: Use new shared result reporting infrastructure Unify the watchPoint() interfaces, move the combined implementation to the DebuggerEngine base. Change-Id: Ic93aa760e7258197aed5eb7bfea257a40012cccf Reviewed-by: hjk <hjk@qt.io>
2016-12-15 18:30:05 +01:00
virtual void watchPoint(const QPoint &pnt);
Debugger: Make DebuggerEngine::runCommand() virtual. Allows default implementation of e.g. stack retrieval in the base class. Change-Id: I96460b19aa31347b2c863736b4ce2b5046eb4de6 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
2015-11-03 12:01:57 +01:00
virtual void runCommand(const DebuggerCommand &cmd);
Debugger: Rework register handling Use register names as handle, not their index in the view. Store the raw real values, not some stringified version as primary data. Use subentries to break down bigger registers into smaller entities. Also remember the previous value of a register and show it in a tooltip. Change-Id: I8ae3cc8766a7b211bc7cc827c734e5cf6060825c Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-17 13:14:29 +01:00
virtual void openMemoryView(const MemoryViewSetupData &data);
Debugger/BinEditor: Standardize interface Change-Id: I4acf6bc7648e57c564e86023176ae3905a293a99 Reviewed-by: Orgad Shaneh <orgads@gmail.com> Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2016-07-14 10:00:15 +02:00
virtual void fetchMemory(MemoryAgent *, quint64 addr, quint64 length);
virtual void changeMemory(MemoryAgent *, quint64 addr, const QByteArray &data);
debugger: move MemoryViewAgent ownership to DebuggerEngine
2010-12-13 18:17:31 +01:00
virtual void updateMemoryViews();
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
virtual void openDisassemblerView(const Internal::Location &location);
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
virtual void fetchDisassembler(Internal::DisassemblerAgent *);
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void activateFrame(int index);
virtual void reloadModules();
virtual void examineModules();
virtual void loadSymbols(const QString &moduleName);
debugger: add an option to load "missing" symbols for current stack
2010-12-21 13:34:59 +01:00
virtual void loadSymbolsForStack();
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void loadAllSymbols();
virtual void requestModuleSymbols(const QString &moduleName);
debugger: give access to the section names in a shared object Via context menu in the modules view, gdb-only for now. Change-Id: I1163540cd9894c52243bb1bf0c2afc881e793863 Reviewed-by: hjk <qthjk@ovi.com>
2012-11-07 18:31:17 +01:00
virtual void requestModuleSections(const QString &moduleName);
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 reloadRegisters();
Debugger: Add peripheral registers description file support This feature is useful for the bare-metal programming. It allows to view the peripheral registers of the debugged device using the GDB. An information about the peripheral registers for a concrete device contains in a special SVD file. A format of this file described e.g. here: * https://www.keil.com/pack/doc/CMSIS/SVD/html/svd_Format_pg.html This feature supported only for ARM devices, and an appropriate SVD files can be found in the Internet, also this files provides by KEIL or IAR EW IDE's. A use case in QtC is that the user should to choose desired SVD file and set its path to the bare-metal device configuration widget. After this, the user can enable the "Peripheral Registers" view, choose a desired register group and to see a peripheral register values. Currently the following basic features are implemented: * Choosing SVD file for a target bare-metal device. * Choosing any peripheral register group, which is available for this device. * Seeing the info about the each peripheral register and its fields. * Seeing the value for the each peripheral register and its fields. * Changing the value for the each peripheral register and its fields (if it is allowed by access for a concrete register or field). * Changing the format of the values (hexadecimal, decimal, octal, binary). Fixes: QTCREATORBUG-18729 Change-Id: I3c38ea50ccd2e128746458f9b918095b4c2d644a Reviewed-by: hjk <hjk@qt.io>
2019-07-28 23:32:33 +03:00
virtual void reloadPeripheralRegisters();
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 reloadSourceFiles();
virtual void reloadFullStack();
Add a stack window menu entry to display QML stack frame. Add language field to stack frame. Add virtual for loading QML stack invoked by stack window context menu, implement for CDB, GDB. Task-number: QTCREATORBUG-11144 Change-Id: Ic39be3978b40d96ed18cb69a8355296ec572ece7 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-02-07 18:10:02 +01:00
virtual void loadAdditionalQmlStack();
Debugger: Add "Reload Debugging Helpers" to Log Window context menu Change-Id: I5059dbf73482236a677de8c004ab33aaef3d4cd6 Reviewed-by: hjk <qthjk@ovi.com>
2013-01-10 12:40:50 +01:00
virtual void reloadDebuggingHelpers();
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
virtual void setRegisterValue(const QString &name, const QString &value);
Debugger: Add peripheral registers description file support This feature is useful for the bare-metal programming. It allows to view the peripheral registers of the debugged device using the GDB. An information about the peripheral registers for a concrete device contains in a special SVD file. A format of this file described e.g. here: * https://www.keil.com/pack/doc/CMSIS/SVD/html/svd_Format_pg.html This feature supported only for ARM devices, and an appropriate SVD files can be found in the Internet, also this files provides by KEIL or IAR EW IDE's. A use case in QtC is that the user should to choose desired SVD file and set its path to the bare-metal device configuration widget. After this, the user can enable the "Peripheral Registers" view, choose a desired register group and to see a peripheral register values. Currently the following basic features are implemented: * Choosing SVD file for a target bare-metal device. * Choosing any peripheral register group, which is available for this device. * Seeing the info about the each peripheral register and its fields. * Seeing the value for the each peripheral register and its fields. * Changing the value for the each peripheral register and its fields (if it is allowed by access for a concrete register or field). * Changing the format of the values (hexadecimal, decimal, octal, binary). Fixes: QTCREATORBUG-18729 Change-Id: I3c38ea50ccd2e128746458f9b918095b4c2d644a Reviewed-by: hjk <hjk@qt.io>
2019-07-28 23:32:33 +03:00
virtual void setPeripheralRegisterValue(quint64 address, quint64 value);
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
virtual void addOptionPages(QList<Core::IOptionsPage*> *) const;
debugger: replace static capability check by something potentially dynamic This does not yet use the potential. Change-Id: I087311fb7d59b46e49f65a84c4420c72a1227ebb Reviewed-by: Aurindam Jana <aurindam.jana@nokia.com>
2012-01-12 20:28:17 +01:00
virtual bool hasCapability(unsigned cap) const = 0;
Debugger: Simplify "debug last command" Let the engine decide what to do. Less magic parsing, less code, and survives cleaning the log view. Change-Id: Ic94f27899d7986fb5ce3d24bb2edce8e6faf899c Reviewed-by: hjk <hjk121@nokiamail.com>
2014-01-04 01:34:51 +01:00
virtual void debugLastCommand() {}
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
virtual QString qtNamespace() const;
void setQtNamespace(const QString &ns);
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: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
virtual void updateLocals();
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Use engine specific contexts for delegating actions Some actions that are engine specific are visible globally in the Debug menu, like stopping, interrupting and continuing the debugger, and various step variants. These are registered in the action manager by the debugger plugin. Avoid duplicating the state management of these actions in the debugger plugin, by registering these actions as disabled dummies. The actual actions of the specific debugger run are now registered in the action manager by the debugger engine instance, for a debugger engine instance specific context. The engine manager sets the engine instance specific context when the UI is switched to the specific debugger run. Change-Id: I0a311cec0856365b830460dec2ce33d14a2289c0 Reviewed-by: hjk <hjk@qt.io>
2018-10-23 15:32:33 +02:00
Core::Context debuggerContext() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual Core::Context languageContext() const { return {}; }
Debugger: Do not remember persistent layout settings per engine Fixes: QTCREATORBUG-21006 Change-Id: Id3c2062eb5b42808d666f0fc3620a82666fe14a2 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2018-09-04 13:29:15 +02:00
QString displayName() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual bool acceptsBreakpoint(const BreakpointParameters &bp) const = 0;
virtual void insertBreakpoint(const Breakpoint &bp) = 0;
virtual void removeBreakpoint(const Breakpoint &bp) = 0;
virtual void updateBreakpoint(const Breakpoint &bp) = 0;
virtual void enableSubBreakpoint(const SubBreakpoint &sbp, bool enabled);
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
debugger: replace action(ExecuteCommand) be a direct function call
2011-02-16 12:41:06 +01:00
virtual bool acceptsDebuggerCommands() const { return true; }
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual void executeDebuggerCommand(const QString &command);
Debugger: Simplify "debug last command" Let the engine decide what to do. Less magic parsing, less code, and survives cleaning the log view. Change-Id: Ic94f27899d7986fb5ce3d24bb2edce8e6faf899c Reviewed-by: hjk <hjk121@nokiamail.com>
2014-01-04 01:34:51 +01:00
Debugger: Remove most remaining occurrences of WatchData ... in WatchHandler and DebuggerEngine interface. Adjust using code. Change-Id: I6371f3e96ba46a783e23a5767cdde24a10d3fce7 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-03-19 12:42:53 +01:00
virtual void assignValueInDebugger(WatchItem *item,
debugger: kill command handler & company
2010-11-08 15:19:13 +01:00
const QString &expr, const QVariant &value);
Debugger: Streamline ThreadHandler - Use the TreeItem/data pattern recently introduced with Breakpoints to remove the need of keeping track of id/object mapping. Opens possibility to have thread groups as intermediate level. - Use the ThreadHandler directly as model for the thread combobox to remove the need of manual combo box updates. - Move setting current thread from individual engines to central code. Change-Id: I030e21a4aa5ab30b0efbc84528d9cecf29cbbe30 Reviewed-by: David Schulz <david.schulz@qt.io>
2018-08-15 17:28:00 +02:00
virtual void selectThread(const Internal::Thread &thread) = 0;
debugger: move convienience function to DebuggerEngine base class
2010-07-21 14:24:29 +02:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual void executeRecordReverse(bool) {}
virtual void executeReverse(bool) {}
ModulesHandler *modulesHandler() const;
RegisterHandler *registerHandler() const;
Debugger: Add peripheral registers description file support This feature is useful for the bare-metal programming. It allows to view the peripheral registers of the debugged device using the GDB. An information about the peripheral registers for a concrete device contains in a special SVD file. A format of this file described e.g. here: * https://www.keil.com/pack/doc/CMSIS/SVD/html/svd_Format_pg.html This feature supported only for ARM devices, and an appropriate SVD files can be found in the Internet, also this files provides by KEIL or IAR EW IDE's. A use case in QtC is that the user should to choose desired SVD file and set its path to the bare-metal device configuration widget. After this, the user can enable the "Peripheral Registers" view, choose a desired register group and to see a peripheral register values. Currently the following basic features are implemented: * Choosing SVD file for a target bare-metal device. * Choosing any peripheral register group, which is available for this device. * Seeing the info about the each peripheral register and its fields. * Seeing the value for the each peripheral register and its fields. * Changing the value for the each peripheral register and its fields (if it is allowed by access for a concrete register or field). * Changing the format of the values (hexadecimal, decimal, octal, binary). Fixes: QTCREATORBUG-18729 Change-Id: I3c38ea50ccd2e128746458f9b918095b4c2d644a Reviewed-by: hjk <hjk@qt.io>
2019-07-28 23:32:33 +03:00
PeripheralRegisterHandler *peripheralRegisterHandler() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
StackHandler *stackHandler() const;
ThreadsHandler *threadsHandler() const;
WatchHandler *watchHandler() const;
SourceFilesHandler *sourceFilesHandler() const;
BreakHandler *breakHandler() const;
LogWindow *logWindow() const;
DisassemblerAgent *disassemblerAgent() 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: 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;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual bool companionPreventsActions() 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: Finalize moving Operate by Instruction to engines Fixes: QTCREATORBUG-21211 Fixes: QTCREATORBUG-21212 Change-Id: I6c0259052336f2141462157c319abeaec9a1e483 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-10-05 12:03:19 +02:00
bool operatesByInstruction() const;
virtual void operateByInstructionTriggered(bool on); // FIXME: Remove.
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
DebuggerState state() 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
Debugger: Remove debuggerstringutils.h With QT_RESTRICTED_CAST_FROM_ASCII making GdbMi etc operate on QString is feasible again. Take this as opportunity to move debugger encoding handling closer to a 'conversion on input and output if needed, storage in QString only' scheme. Change-Id: I2f10c9fa8a6c62c44f4e6682efe3769e9fba30f7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-07 17:04:53 +02:00
static QString stateName(int s);
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: Add more information about the debugee when debugging Fixes: QTCREATORBUG-25159 Change-Id: Ic462c8bb4d9f4f7163dbb9fcc13adce4c7172564 Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io> Reviewed-by: André Hartmann <aha_1980@gmx.de>
2021-03-15 15:14:08 +01:00
void notifyExitCode(int code);
Debugger: Use ProcessHandle in notifyInferiorPid() Change-Id: Idcb6819b64964b6aa0e72d182cc628feba37ba55 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-03-01 09:35:28 +01:00
void notifyInferiorPid(const Utils::ProcessHandle &pid);
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
qint64 inferiorPid() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +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
bool isReverseDebugging() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void handleBeginOfRecordingReached();
void handleRecordingFailed();
void handleRecordReverse(bool);
void handleReverseDirection(bool);
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
// Convenience
Debugger: De-virtualize and de-slot DebuggerEngine::show*Message Apparently not used virtually/weakly anymore, so make it easier to reason about used code paths. Last users apparently were QmlCppEngine and TrkAdapter. Both gone. Change-Id: I5ab7d261362bede9a4cf622f4c124726deca83e8 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2020-02-24 09:16:14 +01:00
void showMessage(const QString &msg, int channel = LogDebug, int timeout = -1) const;
void showStatusMessage(const QString &msg, int timeout = -1) const;
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
QmlCppEngine: Make sure that breakpoint markers get removed resetLocation() called by DebuggerPlugin::handle* should automatically reset the locations for stepping etc. Change-Id: I3e20f93ade7f40e1e1f33b1b48b11522b59771f8 Task-number: QTCREATORBUG-6291 Reviewed-by: Christiaan Janssen <christiaan.janssen@nokia.com>
2011-10-12 17:26:18 +02:00
virtual void resetLocation();
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
virtual void gotoLocation(const Internal::Location &location);
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void gotoCurrentLocation();
Debugger: Streamline ramping down There were only two used target states, and in case of mixed debugging all parts of the machinery better agree on the direction. So one bool in the (shared) runTool is sufficient. Change-Id: Iffbf1651b82dde707cfc37d8da9d3da573b34b76 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-19 11:54:13 +02:00
virtual void quitDebugger(); // called when pressing the stop button
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void abortDebugger();
Debugger: Fix display of location marker when switching perspectives Fixes: QTCREATORBUG-21362 Change-Id: I9bc1f0931ea902d04ab256774347b63c1fc64262 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2018-11-09 11:36:28 +01:00
void updateUi(bool isCurrentEngine);
Debugger: Centralize abort handling ... and apply even more force on the second trying by forcing ramp down of the runControl itself instead of hoping that it would pick up hints. Change-Id: I9d0f4130cb9a137b91c9fa81c3d255f236f98be0 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-19 12:31:19 +02:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
bool isPrimaryEngine() const;
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +02:00
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
virtual bool canDisplayTooltip() const;
QmlDebugger: displaying tooltips while qml is running Reviewed-by: hjk
2011-01-24 16:58:35 +01:00
Debugger: Use kit macro expander instead of global one where possible This is low hanging fruit enabling a lot more customization. Change-Id: I1a90fa731ea512852c12a55fad75551efb44e875 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-03-22 10:47:03 +01:00
QString expand(const QString &string) const;
Debugger: Provide a startup customization hook for 3rd party plugins Change-Id: Ia587abcb1bdcdfbf192d3314610ec9addf370c9b Reviewed-by: David Schulz <david.schulz@qt.io>
2017-01-20 09:38:59 +01:00
QString nativeStartupCommands() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
Utils::Perspective *perspective() const;
void updateMarkers();
Debugger: Split ToolTipManager into per-engine parts Change-Id: If2e601a91ad2a0e5ba30916a5d1f2312ecff944f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-23 15:21:43 +02:00
void updateToolTips();
DebuggerToolTipManager *toolTipManager();
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
signals:
void engineStarted();
void engineFinished();
void requestRunControlFinish();
void requestRunControlStop();
void attachToCoreRequested(const QString &coreFile);
void appendMessageRequested(const QString &msg,
Utils::OutputFormat format,
bool appendNewLine) const;
Debugger: Use kit macro expander instead of global one where possible This is low hanging fruit enabling a lot more customization. Change-Id: I1a90fa731ea512852c12a55fad75551efb44e875 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-03-22 10:47:03 +01: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: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
void notifyEngineSetupOk();
void notifyEngineSetupFailed();
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: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
void notifyEngineRunAndInferiorRunOk();
void notifyEngineRunAndInferiorStopOk();
void notifyEngineRunOkAndInferiorUnrunnable(); // Called by CoreAdapter.
debugger: more state work
2010-07-13 08:41:27 +02:00
// Use notifyInferiorRunRequested() plus notifyInferiorRunOk() instead.
Debugger: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
// 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: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
void notifyInferiorRunRequested();
void notifyInferiorRunOk();
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: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void notifyInferiorIll();
void notifyInferiorExited();
Debugger: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
void notifyInferiorStopOk();
void notifyInferiorSpontaneousStop();
void notifyInferiorStopFailed();
Debugger: Make DebuggerEngine internal Expose less of debugger internals to the device plugins. Change-Id: Ie78756b033fae3fe02bff92eadf26b7319990605 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com> Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-12 15:33:16 +01:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
public:
Debugger: Re-organize dock widget persisting Looks like the mainwindow cannot be convinced to handle multiple sets of dockwidgets. So switch back to a single set containing everything and keep track of non-default visibility in the perspectives, and persist these sets. The following pass: 1. Start Creator with new settings Goto Debug Mode Move Break dock widget to right, switch on Global log widget Leave Creator Start Creator Goto Debug Mode Check: Debugger Selected, Break on right, Global log visible 2. Start Creator with new settings Goto Debug Mode Move Break dock widget to right, switch on Global log widget Switch to QmlProfiler sub-perspective Leave Creator Start Creator Goto Debug Mode Check QmlProfiler selected Switch to Debugger sub-perspective Check: Debugger Selected, Break on right, Global log visible 3. Start Creator with new settings Use any C++ test project Start debugging / stop at main() (F10) Wait for stop Switch to Edit mode Switch back to Debug mode Check: Only "running" debugger dock widget layout present (not the normal + preset at the same time) Quit Qt Creator while this debugger is running Check: Shuts down without crash 4. Use any C++ test project Start debugging Switch to Debugger Preset perspective Start a second debugger Kill either instance Check: Application dies, Debugger Preset perspective gets displayed Switch to perspective of second instance Check: Perspective looks ok (docks visible as before) Task-number: QTCREATORBUG-21083 Task-number: QTCREATORBUG-21669 Task-number: QTCREATORBUG-21668 Task-number: QTCREATORBUG-21813 Task-number: QTCREATORBUG-21851 Task-number: QTCREATORBUG-22110 Task-number: QTCREATORBUG-22169 Task-number: QTCREATORBUG-22189 Change-Id: Ic9eb41ff7699ac0f48a85e68376daa80b2b6847e Reviewed-by: Robert Loehning <robert.loehning@qt.io> Reviewed-by: Alessandro Portale <alessandro.portale@qt.io>
2019-03-22 07:35:48 +01:00
void updateState();
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
QString formatStartParameters() const;
WatchTreeView *inspectorView();
void updateLocalsWindow(bool showReturn);
void raiseWatchersWindow();
Debugger: Do not remember persistent layout settings per engine Fixes: QTCREATORBUG-21006 Change-Id: Id3c2062eb5b42808d666f0fc3620a82666fe14a2 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2018-09-04 13:29:15 +02:00
QString debuggerName() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
bool isRegistersWindowVisible() const;
Debugger: Add peripheral registers description file support This feature is useful for the bare-metal programming. It allows to view the peripheral registers of the debugged device using the GDB. An information about the peripheral registers for a concrete device contains in a special SVD file. A format of this file described e.g. here: * https://www.keil.com/pack/doc/CMSIS/SVD/html/svd_Format_pg.html This feature supported only for ARM devices, and an appropriate SVD files can be found in the Internet, also this files provides by KEIL or IAR EW IDE's. A use case in QtC is that the user should to choose desired SVD file and set its path to the bare-metal device configuration widget. After this, the user can enable the "Peripheral Registers" view, choose a desired register group and to see a peripheral register values. Currently the following basic features are implemented: * Choosing SVD file for a target bare-metal device. * Choosing any peripheral register group, which is available for this device. * Seeing the info about the each peripheral register and its fields. * Seeing the value for the each peripheral register and its fields. * Changing the value for the each peripheral register and its fields (if it is allowed by access for a concrete register or field). * Changing the format of the values (hexadecimal, decimal, octal, binary). Fixes: QTCREATORBUG-18729 Change-Id: I3c38ea50ccd2e128746458f9b918095b4c2d644a Reviewed-by: hjk <hjk@qt.io>
2019-07-28 23:32:33 +03:00
bool isPeripheralRegistersWindowVisible() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
bool isModulesWindowVisible() const;
void openMemoryEditor();
Debugger: Move showModule{Sections,Symbols} to DebuggerEngine A bit closer to where the functions are used. No real change. Change-Id: Icbad68bd31d85caa59980316537ee532faf2d7ef Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2019-09-19 16:36:43 +02:00
static void showModuleSymbols(const QString &moduleName, const QVector<Symbol> &symbols);
static void showModuleSections(const QString &moduleName, const QVector<Section> &sections);
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void handleExecDetach();
void handleExecContinue();
void handleExecInterrupt();
void handleUserStop();
void handleAbort();
void handleReset();
Debugger: Rework step{In,Out,Over} handling Main menu action pass operation to current engine, everything else is handled there. Combine execute{Step,Next} and execute{Step,Next}I functions. Implementation were mostly similar, in some cases unneeded (the instruction-wise version e.g. for Python) Drop GDB-isms 'step', 'next' in favor of 'step in' and 'step over'. Change-Id: I232232bc7a67d9d297a74f1c81dc43be96787d34 Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-10-02 12:53:07 +02:00
void handleExecStepIn();
void handleExecStepOver();
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void handleExecStepOut();
void handleExecReturn();
void handleExecJumpToLine();
void handleExecRunToLine();
void handleExecRunToSelectedFunction();
void handleAddToWatchWindow();
void handleFrameDown();
void handleFrameUp();
// Breakpoint state transitions
void notifyBreakpointInsertProceeding(const Breakpoint &bp);
void notifyBreakpointInsertOk(const Breakpoint &bp);
void notifyBreakpointInsertFailed(const Breakpoint &bp);
void notifyBreakpointChangeOk(const Breakpoint &bp);
void notifyBreakpointChangeProceeding(const Breakpoint &bp);
void notifyBreakpointChangeFailed(const Breakpoint &bp);
void notifyBreakpointPending(const Breakpoint &bp);
void notifyBreakpointRemoveProceeding(const Breakpoint &bp);
void notifyBreakpointRemoveOk(const Breakpoint &bp);
void notifyBreakpointRemoveFailed(const Breakpoint &bp);
void notifyBreakpointNeedsReinsertion(const Breakpoint &bp);
Debugger: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
protected:
void setDebuggerName(const QString &name);
Debugger: Merge GDB/LLDB process error handling This also removes some of the "illegal" state transitions, partially addressing QTCREATORBUG-14089. Change-Id: I817d87a0b5e0a40285bc9b0880fef5bceaee3f16 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-03-05 11:11:32 +01:00
void notifyDebuggerProcessFinished(int exitCode, QProcess::ExitStatus exitStatus,
const QString &backendName);
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: Fix QmlInspector state update connection Change-Id: I1693d593ec08c14c48b2c2800ce2f240f9e5f438 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-19 13:14:44 +02:00
virtual void setState(DebuggerState state, bool forced = false);
Debugger: Combine the InferiorShutdown{Ok,Failed} states ... into a InferiorShutdownFinished. Change-Id: Icb5394f38f52f7cf300dc83f4eb8f2f0777bbcba Reviewed-by: David Schulz <david.schulz@qt.io>
2017-12-14 09:36:41 +01:00
void notifyInferiorShutdownFinished();
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: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
void notifyEngineSpontaneousShutdown();
Debugger: Combine the EngineShutdown{Ok,Failed} states ... into a EngineShutdownFinished. They were never handled differently, and the only option is to proceed to DebuggerFinished anyway. So simplify the state machine a bit. Change-Id: Ied3be86fff6750abca578dc6788e4be1d895692b Reviewed-by: David Schulz <david.schulz@qt.io>
2017-12-14 09:11:16 +01:00
void notifyEngineShutdownFinished();
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
Debugger: De-virtualize *Engine::notify* functions Most were never re-implemented, so just for debugging purposes in the mixed engine. Change-Id: If569e0e553e3fdd5ef83b3bdfdbd22fd0ad5b90f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-12 10:33:59 +02:00
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 shutdownInferior() = 0;
virtual void shutdownEngine() = 0;
GdbDebugger: add fast restart for debugging Change-Id: Ie51847de912748d05a6b208bec82fd612d777202 Reviewed-by: hjk <hjk121@nokiamail.com> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
2014-06-05 17:22:51 +02:00
virtual void resetInferior() {}
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual void detachDebugger() {}
Debugger: Rework step{In,Out,Over} handling Main menu action pass operation to current engine, everything else is handled there. Combine execute{Step,Next} and execute{Step,Next}I functions. Implementation were mostly similar, in some cases unneeded (the instruction-wise version e.g. for Python) Drop GDB-isms 'step', 'next' in favor of 'step in' and 'step over'. Change-Id: I232232bc7a67d9d297a74f1c81dc43be96787d34 Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-10-02 12:53:07 +02:00
virtual void executeStepOver(bool /*byInstruction*/ = false) {}
virtual void executeStepIn(bool /*byInstruction*/ = false) {}
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual void executeStepOut() {}
virtual void executeReturn() {}
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual void continueInferior() {}
virtual void interruptInferior() {}
Debugger: Pass interrupt request more directly to engines De-virtualize requestInterruptInferior() and let always the master engine react to the request. interruptInferior() diverts to the active slave in case of the combined engine. Change-Id: I5d62cf9379c8a452132827897a9ac51e4027f595 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-16 13:30:53 +02:00
void requestInterruptInferior();
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
virtual void executeRunToLine(const Internal::ContextData &) {}
virtual void executeRunToFunction(const QString &) {}
virtual void executeJumpToLine(const Internal::ContextData &) {}
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01:00
virtual void frameUp();
virtual void frameDown();
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
virtual void doUpdateLocals(const UpdateParameters &params);
Debugger: Move external terminal into separate RunWorker Change-Id: Ifb9701f840195ba90db48a0f6fa07b28e0409648 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-27 08:22:02 +02:00
TerminalRunner *terminal() const;
debugger: code cosmetics
2010-07-08 15:06:09 +02:00
Debugger: Introduce common messages to engine. Try to achieve consistency in reporting stop messages for all engines. Report by BreakpointId if available.
2010-11-17 17:16:34 +01:00
static QString msgStopped(const QString &reason = QString());
static QString msgStoppedBySignal(const QString &meaning, const QString &name);
debugger: polish module symbols
2010-11-26 09:58:34 +01:00
static QString msgStoppedByException(const QString &description,
const QString &threadId);
Debugger: Introduce common messages to engine. Try to achieve consistency in reporting stop messages for all engines. Report by BreakpointId if available.
2010-11-17 17:16:34 +01:00
static QString msgInterrupted();
Debugger: Avoid messagesboxes on the same topic at the same time Task-number: QTCREATORBUG-16971 Change-Id: I625f04cbd8f609c66597450dbad22ebc6eadcfe5 Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2016-12-14 09:59:49 +01:00
bool showStoppedBySignalMessageBox(const QString meaning, QString name);
Debugger: Introduce common messages to engine. Try to achieve consistency in reporting stop messages for all engines. Report by BreakpointId if available.
2010-11-17 17:16:34 +01:00
void showStoppedByExceptionMessageBox(const QString &description);
Debugger: Fix display of expandable items in GDB and LLDB Move common code to dumper.py and debuggerengine.cpp and fix it there. Change-Id: I20d91d1aa7400fbdb27938c10cf40c8f6019df0a Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-03-26 13:03:38 +01:00
void updateLocalsView(const GdbMi &all);
Debugger: Slim down CHECK_STATE() expansion Less generated code. Change-Id: Iafcafc875afa3ead12e10fd5f316d9663b2f9823 Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
2015-09-11 16:51:11 +02:00
void checkState(DebuggerState state, const char *file, int line);
Debugger: Infrastructure for reworked native mixed debugging - Remove old experimental native mixed approach. - Move some common stack parsing to Stackhandler. - Mark gdbbridge.py debug output explicitly to remove it from actual reponse handling New native mixed needs QtDeclarative changes and QTC_DEBUGGER_NATIVE_MIXED=1 for now. Change-Id: I09eed1da51cea878636d36756015b7bfaed34203 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-10-08 16:19:57 +02:00
bool isNativeMixedEnabled() const;
bool isNativeMixedActive() const;
bool isNativeMixedActiveFrame() const;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void startDying() const;
ProjectExplorer::IDevice::ConstPtr device() const;
DebuggerEngine *companionEngine() const;
Debugger: Fix display of expandable items in GDB and LLDB Move common code to dumper.py and debuggerengine.cpp and fix it there. Change-Id: I20d91d1aa7400fbdb27938c10cf40c8f6019df0a Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-03-26 13:03:38 +01:00
debugger: work on action handling
2010-06-22 17:18:29 +02:00
private:
Debugger: Make DebuggerEngine internal Expose less of debugger internals to the device plugins. Change-Id: Ie78756b033fae3fe02bff92eadf26b7319990605 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com> Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-12 15:33:16 +01:00
friend class DebuggerPluginPrivate;
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
friend class DebuggerEnginePrivate;
Debugger: Make LocationMark draggable Issue a DebuggerEngine::executeJumpToLine() in response. Change-Id: I7be5738241ce91f61002d6f6b49c796824569024 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-16 08:14:17 +02:00
friend class LocationMark;
Debugger: Add peripheral registers description file support This feature is useful for the bare-metal programming. It allows to view the peripheral registers of the debugged device using the GDB. An information about the peripheral registers for a concrete device contains in a special SVD file. A format of this file described e.g. here: * https://www.keil.com/pack/doc/CMSIS/SVD/html/svd_Format_pg.html This feature supported only for ARM devices, and an appropriate SVD files can be found in the Internet, also this files provides by KEIL or IAR EW IDE's. A use case in QtC is that the user should to choose desired SVD file and set its path to the bare-metal device configuration widget. After this, the user can enable the "Peripheral Registers" view, choose a desired register group and to see a peripheral register values. Currently the following basic features are implemented: * Choosing SVD file for a target bare-metal device. * Choosing any peripheral register group, which is available for this device. * Seeing the info about the each peripheral register and its fields. * Seeing the value for the each peripheral register and its fields. * Changing the value for the each peripheral register and its fields (if it is allowed by access for a concrete register or field). * Changing the format of the values (hexadecimal, decimal, octal, binary). Fixes: QTCREATORBUG-18729 Change-Id: I3c38ea50ccd2e128746458f9b918095b4c2d644a Reviewed-by: hjk <hjk@qt.io>
2019-07-28 23:32:33 +03:00
friend class PeripheralRegisterHandler;
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;
};
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
class CppDebuggerEngine : public DebuggerEngine
{
public:
CppDebuggerEngine() {}
~CppDebuggerEngine() override {}
Debugger: Make validateExecutable a validateRunParameters Gets rid of the odd and otherwise unused DebuggerEngine::mutableRunParameters() function. Change-Id: Ib0861432e7c61072db2968acf2f36c7f2d56c89a Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-11-13 09:20:24 +01:00
void validateRunParameters(DebuggerRunParameters &rp) override;
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
Core::Context languageContext() const override;
};
Debugger: Restrict LocationMark dragging ... to engines that actually support JumpToLine and make it work in disassembler views. Change-Id: I10368ea719587caa7c4f33665eff57c2bf300d84 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-17 16:33:25 +02:00
class LocationMark : public TextEditor::TextMark
{
public:
Utils: Rename FileName to FilePath More in line with QFileInfo terminonlogy which appears to be best-of-breed within Qt. Change-Id: I1d051ff1c8363ebd4ee56376451df45216c4c9ab Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
2019-05-28 13:49:26 +02:00
LocationMark(DebuggerEngine *engine, const Utils::FilePath &file, int line);
Debugger: Correctly unset LocationMark when the editor is closed. Change-Id: Ib178db5fd7d0e5674326287a471daf0e98a706d9 Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
2015-09-01 15:05:08 +02:00
void removedFromEditor() override { updateLineNumber(0); }
Debugger: Restrict LocationMark dragging ... to engines that actually support JumpToLine and make it work in disassembler views. Change-Id: I10368ea719587caa7c4f33665eff57c2bf300d84 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-17 16:33:25 +02:00
Debugger: Make most views per-engine instead of singletons This is a step towards properly supporting multiple debugger sessions side-by-side. The combined C++-and-QML engine has been removed, instead a combined setup creates now two individual engines, under a single DebuggerRunTool but mostly independent with no combined state machine. This requires a few more clicks in some cases, but makes it easier to direct e.g. interrupt requests to the interesting engine. Care has been taken to not change the UX of the single debugger session use case if possible. The fat debug button operates as-before in that case, i.e. switches to Interrupt if the single active runconfiguration runs in the debugger etc. Most views are made per-engine, running an engine creates a new Perspective, which is destroyed when the run control dies. The snapshot view remains global and becomes primary source of information on a "current engine" that receives all menu and otherwise global input. There is a new global "Breakpoint Preset" view containing all "static" breakpoint data. When an engine starts up it "claims" breakpoint it believes it can handle, but operates on a copy of the static data. The markers of the static version are suppressed as long as an engine controls a breakpoint (that inclusive all resolved locations), but are re-instatet once the engine quits. The old Breakpoint class that already contained this split per-instance was split into a new Breakpoint and a GlobalBreakpoint class, with a per-engine model for Breakpoints, and a singleton model containing GlobalBreakpoints. There is a new CppDebuggerEngine intermediate level serving as base for C++ (or, rather, "compiled") binary debugging, i.e. {Gdb,Lldb,Cdb}Engine, taking over bits of the current DebuggerEngine base that are not applicable to non-binary debuggers. Change-Id: I9994f4c188379b4aee0c4f379edd4759fbb0bd43 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2018-07-31 12:30:48 +02:00
void updateIcon();
Debugger: Restrict LocationMark dragging ... to engines that actually support JumpToLine and make it work in disassembler views. Change-Id: I10368ea719587caa7c4f33665eff57c2bf300d84 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-17 16:33:25 +02:00
private:
Debugger: Add some missing overrides Quieten some warnings about inconsistent override usage. Change-Id: I12bea62b17198c39cca05b53da6cf2590afc3b6b Reviewed-by: hjk <hjk@theqtcompany.com>
2015-09-09 11:55:30 +02:00
bool isDraggable() const override;
void dragToLine(int line) override;
Debugger: Restrict LocationMark dragging ... to engines that actually support JumpToLine and make it work in disassembler views. Change-Id: I10368ea719587caa7c4f33665eff57c2bf300d84 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-17 16:33:25 +02:00
QPointer<DebuggerEngine> m_engine;
};
Debugger: Make DebuggerEngine internal Expose less of debugger internals to the device plugins. Change-Id: Ie78756b033fae3fe02bff92eadf26b7319990605 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com> Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com> Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-12-12 15:33:16 +01:00
} // namespace Internal
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
} // namespace Debugger
Debugger: Consolidate GDB and LLDB "updateLocals" code paths This splits the bool setToolTipExpression() operation into a bool canHandleToolTip(), and the actual processing of the request, which is mostly identical to the handling of a watcher. Handling a watcher is now mostly the same as a full Locals update, except for the 'partial' flag. Pushing the handling of that down to the bridges gives identical code paths in the gdb and lldbengine. Move that to the DebuggerEngine base class. Change-Id: I3861b43e8630c7e7bd57fcd549b2a2387e3d4869 Reviewed-by: hjk <hjk@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-06-08 18:07:11 +02:00
Q_DECLARE_METATYPE(Debugger::Internal::UpdateParameters)
debugger: fix 'Jump To/Run to' when in instruction-wise mode
2011-02-23 10:16:11 +01:00
Q_DECLARE_METATYPE(Debugger::Internal::ContextData)
Copy Permalink