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

2690 lines
86 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
#include "debuggerengine.h"
Debugger: Separate internal constants.
2011-04-21 15:52:51 +02:00
#include "debuggerinternalconstants.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
#include "debuggeractions.h"
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
#include "debuggercore.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 "debuggerdialogs.h"
Debugger: Consolidate icon storage handling We settled now on global objects being fine for the purpose in Core and ProjectExplorer, so there's no point in using something more fancy in the debugger. Change-Id: I72e45f398c09d22894419c274dfbea77da0fc153 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-06-27 14:38:36 +02:00
#include "debuggericons.h"
Debugger: Consolidate RunControl creation Export factory, de-export plugin, to remove one indirection Change-Id: I13a46460d07d5ded6b26f2b5ceccd01142fb10e8 Reviewed-by: Christian Stenger <christian.stenger@digia.com>
2014-10-17 13:40:04 +02:00
#include "debuggerruncontrol.h"
Debugger: Rework editor tooltips handling Fix expansion and updating. Persistence and non-locals are still lacking. Change-Id: I74e25199d50350516afc686a05836e239bfc8acb Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-07-10 18:10:56 +02:00
#include "debuggertooltipmanager.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
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 "analyzer/analyzermanager.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
#include "breakhandler.h"
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
#include "disassembleragent.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 "localsandexpressionswindow.h"
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
#include "logwindow.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 "debuggermainwindow.h"
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
#include "memoryagent.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
#include "moduleshandler.h"
#include "registerhandler.h"
#include "sourcefileshandler.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 "sourceutils.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
#include "stackhandler.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 "stackwindow.h"
#include "snapshothandler.h"
Debugger: Introduce a pty based channel to inferiors This is experimental for now and requires QTC_USE_PTY=1 in the environment to be used. Change-Id: I460ce7b9283467d481e903f731f4243b7e5ec094 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-01-14 16:58:10 +01:00
#include "terminal.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
#include "threadshandler.h"
#include "watchhandler.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 "watchutils.h"
#include "watchwindow.h"
Move QmlConsole to Debugger Now it is closer to its only user and possibly reusable for no-QML uses there. We also drop the QML/JS syntax checker. The application being debugged can already tell us about syntax errors. There is no need to duplicate that functionality. Change-Id: I2ba151f9f4c854c6119ba5462c21be40bddcebf9 Reviewed-by: Ulf Hermann <ulf.hermann@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-11-10 16:59:02 +01:00
#include "debugger/shared/peutils.h"
#include "console/console.h"
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
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/actionmanager/actionmanager.h>
debugger: code cosmetics
2010-12-14 16:10:19 +01:00
#include <coreplugin/editormanager/editormanager.h>
Remove internal class BaseTextMarkRegistry from exported header. Change-Id: Ieeffe65be2d7c8f07f41f7211853d616a6aceb85 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
2013-03-26 11:32:14 +01:00
#include <coreplugin/editormanager/ieditor.h>
Debugger: Simplify raise-on-stop logic Also slightly change meaning (now all stops may cause raising). Change-Id: Ie3fee7371ab119e4e9747dc44a4d8ef2cd62c8d8 Reviewed-by: Eike Ziller <eike.ziller@digia.com>
2014-05-22 17:56:14 +02:00
#include <coreplugin/icore.h>
Clean exported headers of the Core plugin. Change-Id: I26472d568844d5fee62323e01f5c5c12082d5450 Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2015-02-26 13:38:54 +01:00
#include <coreplugin/idocument.h>
Debugger: Use Core::AsynchronousMessageBox Nested event loops can lead to crashes, so it is better to use a dialog which does not have have its own event loop. Change-Id: Icd2390c9026bc1ef88e72a570df5813fe5cbdaa2 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-11-25 13:08:18 +01:00
#include <coreplugin/messagebox.h>
debugger: move progress handling to debugger engine base class
2010-07-21 11:02:51 +02:00
#include <coreplugin/progressmanager/progressmanager.h>
#include <coreplugin/progressmanager/futureprogress.h>
debugger: work on action handling
2010-06-22 17:18:29 +02:00
taskhub: use more direct access. Change-Id: Ibc4f37589f913ff9ea0025156979ddda73929e38 Reviewed-by: Tobias Hunger <tobias.hunger@nokia.com>
2012-03-07 16:40:03 +01:00
#include <projectexplorer/projectexplorer.h>
debugger: use tasklist for tasks generated by the "automated manual" test Change-Id: Ife3830e12cd3f44c29dc3e531f104ffb894efe0f Reviewed-by: hjk <qthjk@ovi.com>
2011-11-25 17:45:07 +01:00
#include <projectexplorer/taskhub.h>
TextEditor: More BaseText* -> Text* renamings *Document* and *Layout* classes, all basetext* files Change-Id: I1c6e376733a434fcb5c7f19c6210dfa031eeafde Reviewed-by: Eike Ziller <eike.ziller@digia.com>
2014-09-26 09:14:03 +02:00
#include <texteditor/texteditor.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 <texteditor/texteditorsettings.h>
#include <texteditor/fontsettings.h>
Remove internal class BaseTextMarkRegistry from exported header. Change-Id: Ieeffe65be2d7c8f07f41f7211853d616a6aceb85 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@digia.com>
2013-03-26 11:32:14 +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
#include <utils/basetreeview.h>
ScriptConsole: Show File and Line Info Show File and Line Info for items that have the info. Clicking on the item opens the file and sets the cursor position on the line. The context menu also provides option to copy contents and option to clear the view. Change-Id: I161de392ba35e37d323b049371619b01c617c798 Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
2012-02-22 11:50:05 +01:00
#include <utils/fileinprojectfinder.h>
VariableChooser: Rework Allow multiple expanders to be registered for lineedits, e.g. a local and the global ones, and actually show them. Use a tree view in the chooser for somewhat more structured display. Change-Id: I769f92144e5249f45e54381de52aa6973eb20118 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2014-10-13 18:49:44 +02:00
#include <utils/macroexpander.h>
ProjectExplorer: Move ProcessHandle to Utils for further re-use Also, use qint64 instead of quint64, as this is what Qt uses. Keep 0 for invalid PIDs, even if arguably -1 would be better, but Qt uses 0, too. Don't move 'toString', instead inline it into the only caller, keeping translations intact. Task-number: QTCREATORBUG-17596 Change-Id: Ie9411ea1d2031a5ab0a99bcb3ff48ee430afe254 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-01-16 15:53:53 +01:00
#include <utils/processhandle.h>
VariableChooser: Rework Allow multiple expanders to be registered for lineedits, e.g. a local and the global ones, and actually show them. Use a tree view in the chooser for somewhat more structured display. Change-Id: I769f92144e5249f45e54381de52aa6973eb20118 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2014-10-13 18:49:44 +02:00
#include <utils/qtcassert.h>
Debugger: Merge prepareCommand Change-Id: Idd316a88ae39d563c99d3b4081f88fc41e604499 Reviewed-by: hjk <hjk@qt.io>
2017-04-19 10:10:23 +02:00
#include <utils/qtcprocess.h>
VariableChooser: Rework Allow multiple expanders to be registered for lineedits, e.g. a local and the global ones, and actually show them. Use a tree view in the chooser for somewhat more structured display. Change-Id: I769f92144e5249f45e54381de52aa6973eb20118 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2014-10-13 18:49:44 +02:00
#include <utils/savedaction.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 <utils/styledbar.h>
#include <utils/utilsicons.h>
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
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 <QApplication>
#include <QComboBox>
Removed module names from #include directives. Getting the #include directives ready for Qt5. This includes the new-project wizards. Change-Id: Ia9261f1e8faec06b9285b694d2b7e9a095978d2b Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
2012-02-15 10:42:41 +01:00
#include <QDebug>
lldb: Quick fix for weird behavior when opening locations from debugger Paths passed to Qt Creator API must be cleaned. Make sure that the file path that is opened from stack view and when stepping etc, is cleaned. Task-number: QTCREATORBUG-10119 Change-Id: Iaac9b15e76cf8dff514889f201c4f65330145d16 Reviewed-by: hjk <hjk121@nokiamail.com>
2013-10-17 17:25:05 +02:00
#include <QDir>
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 <QDockWidget>
#include <QFileInfo>
#include <QHeaderView>
#include <QTextBlock>
#include <QTimer>
#include <QToolButton>
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: 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
#include <QJsonArray>
#include <QJsonDocument>
#include <QJsonObject>
#include <QJsonValue>
debugger: work on action handling
2010-06-22 17:18:29 +02:00
using namespace Core;
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
using namespace Debugger::Internal;
debugger: work on action handling
2010-06-22 17:18:29 +02:00
using namespace ProjectExplorer;
using namespace TextEditor;
ProjectExplorer: Move ProcessHandle to Utils for further re-use Also, use qint64 instead of quint64, as this is what Qt uses. Keep 0 for invalid PIDs, even if arguably -1 would be better, but Qt uses 0, too. Don't move 'toString', instead inline it into the only caller, keeping translations intact. Task-number: QTCREATORBUG-17596 Change-Id: Ie9411ea1d2031a5ab0a99bcb3ff48ee430afe254 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2017-01-16 15:53:53 +01:00
using namespace 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
debugger: make debuggerengine easier accessible to profiling Change-Id: I5c9ed1e994e490a6a6859afc6ae1756b09b87af9 Reviewed-by: hjk <qthjk@ovi.com>
2012-05-08 16:50:03 +02:00
//#define WITH_BENCHMARK
#ifdef WITH_BENCHMARK
#include <valgrind/callgrind.h>
#endif
debugger: move more gui bit from engine to plugin
2010-11-08 15:41:44 +01:00
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
namespace Debugger {
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
QDebug operator<<(QDebug d, DebuggerState state)
{
debugger: more state work
2010-07-13 08:41:27 +02:00
//return d << DebuggerEngine::stateName(state) << '(' << int(state) << ')';
return d << DebuggerEngine::stateName(state);
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: 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
QDebug operator<<(QDebug str, const DebuggerRunParameters &sp)
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
{
QDebug nospace = str.nospace();
Debugger: Use StandardRunnable in DebuggerStartParameters This is a mechanical replacement for the former executable, processArgs, inferiorEnvironment and workingDirectory members. Change-Id: I4160e01427ed801df9b729f1f31d0a2ca48159b5 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-01-28 10:31:24 +01:00
nospace << "executable=" << sp.inferior.executable
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
<< " coreFile=" << sp.coreFile
Debugger: Use StandardRunnable in DebuggerStartParameters This is a mechanical replacement for the former executable, processArgs, inferiorEnvironment and workingDirectory members. Change-Id: I4160e01427ed801df9b729f1f31d0a2ca48159b5 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-01-28 10:31:24 +01:00
<< " processArgs=" << sp.inferior.commandLineArguments
<< " inferior environment=<" << sp.inferior.environment.size() << " variables>"
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
<< " debugger environment=<" << sp.debugger.environment.size() << " variables>"
Debugger: Use StandardRunnable in DebuggerStartParameters This is a mechanical replacement for the former executable, processArgs, inferiorEnvironment and workingDirectory members. Change-Id: I4160e01427ed801df9b729f1f31d0a2ca48159b5 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-01-28 10:31:24 +01:00
<< " workingDir=" << sp.inferior.workingDirectory
Debugger: Use Utils::ProcessHandle for DebuggerEngine::m_inferiorPid That's the intended "typesafe" use. Change-Id: Ib288fe87a47bd9484bda83e05406f0d22989b3c2 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-02-27 13:30:08 +01:00
<< " attachPID=" << sp.attachPID.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
<< " remoteChannel=" << sp.remoteChannel
ToolChain: Refactor toolchain support Refactor ToolChains in Qt Creator: * Allow for several toolchains of the same type * Be smarter wrt. guessing what kind of output a toolchain produces. This allows us to eventually handle e.g. embedded linux setups way better than before. * Be smarter wrt. guessing what kind of environment a Qt version needs. * Improve auto-detection of toolchains a bit * Decide on which debugger to use based on the kind of output produced by the compiler. * Add options page to configure toolchains * Remove toolchain related options from the Qt version dialog Reviewed-by: dt
2011-02-01 18:36:00 +01:00
<< " abi=" << sp.toolChainAbi.toString() << '\n';
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
return str;
}
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: 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
static bool debuggerActionsEnabledHelper(DebuggerState state)
{
switch (state) {
case InferiorRunOk:
case InferiorUnrunnable:
case InferiorStopOk:
return true;
case InferiorStopRequested:
case InferiorRunRequested:
case InferiorRunFailed:
case DebuggerNotReady:
case EngineSetupRequested:
case EngineSetupOk:
case EngineSetupFailed:
case EngineRunRequested:
case EngineRunFailed:
case InferiorStopFailed:
case InferiorShutdownRequested:
case InferiorShutdownFinished:
case EngineShutdownRequested:
case EngineShutdownFinished:
case DebuggerFinished:
return false;
}
return false;
}
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
Location::Location(const StackFrame &frame, bool marker)
{
m_fileName = frame.file;
m_lineNumber = frame.line;
m_needsMarker = marker;
m_functionName = frame.function;
m_hasDebugInfo = frame.isUsable();
m_address = frame.address;
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
m_from = frame.module;
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: more breakpoint management related fixes
2010-06-22 15:37:27 +02:00
Use FileName in TextMark Change-Id: I3666d95dc8ef3b7da099d6d30f5cb4678a349493 Reviewed-by: David Schulz <david.schulz@qt.io>
2018-05-02 15:02:00 +02:00
LocationMark::LocationMark(DebuggerEngine *engine, const FileName &file, int line)
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
: TextMark(file, line, Constants::TEXT_MARK_CATEGORY_LOCATION), m_engine(engine)
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
{
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
setPriority(TextMark::HighPriority);
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
updateIcon();
}
void LocationMark::updateIcon()
{
const Icon *icon = &Icons::WATCHPOINT;
if (m_engine && EngineManager::currentEngine() == m_engine)
icon = m_engine->isReverseDebugging() ? &Icons::REVERSE_LOCATION : &Icons::LOCATION;
setIcon(icon->icon());
updateMarker();
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 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
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
bool LocationMark::isDraggable() 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
return m_engine && m_engine->hasCapability(JumpToLineCapability);
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 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
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
void LocationMark::dragToLine(int line)
{
if (m_engine) {
Debugger: Recognize source data within disassembler view ... and use it to toggle breakpoints by file and line, and for jumping to file and line. Task-number: QTCREATORBUG-14278 Change-Id: I799d085eb53339905ea3608022aeae5a9aef1fda Reviewed-by: Niels Weber <niels.weber@theqtcompany.com> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-07-20 09:37:54 +02:00
if (BaseTextEditor *textEditor = BaseTextEditor::currentTextEditor()) {
ContextData location = getLocationContext(textEditor->textDocument(), line);
if (location.isValid())
m_engine->executeJumpToLine(location);
}
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
}
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 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
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
//////////////////////////////////////////////////////////////////////
//
// MemoryAgentSet
//
//////////////////////////////////////////////////////////////////////
class MemoryAgentSet
{
public:
~MemoryAgentSet()
{
qDeleteAll(m_agents);
m_agents.clear();
}
// Called by engine to create a new view.
void createBinEditor(const MemoryViewSetupData &data, DebuggerEngine *engine)
{
auto agent = new MemoryAgent(data, engine);
if (agent->isUsable()) {
m_agents.append(agent);
} else {
delete agent;
AsynchronousMessageBox::warning(
DebuggerEngine::tr("No Memory Viewer Available"),
DebuggerEngine::tr("The memory contents cannot be shown as no viewer plugin "
"for binary data has been loaded."));
}
}
// On stack frame completed and on request.
void updateContents()
{
foreach (MemoryAgent *agent, m_agents) {
if (agent)
agent->updateContents();
}
}
void handleDebuggerFinished()
{
foreach (MemoryAgent *agent, m_agents) {
if (agent)
agent->setFinished(); // Prevent triggering updates, etc.
}
}
private:
QList<MemoryAgent *> m_agents;
};
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
//
//////////////////////////////////////////////////////////////////////
debugger: reenable disabling of breakpoints in editor context menu
2010-06-25 16:06:48 +02:00
class DebuggerEnginePrivate : 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
{
debugger: reenable disabling of breakpoints in editor context menu
2010-06-25 16:06:48 +02:00
Q_OBJECT
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
public:
Debugger: Move run parameters from engine to tool runner The parameters belong to the run control, they should not be triplicated in case of a combined engine. Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-05 14:45:36 +02:00
DebuggerEnginePrivate(DebuggerEngine *engine)
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
: m_engine(engine),
m_breakHandler(engine),
m_modulesHandler(engine),
m_registerHandler(engine),
m_sourceFilesHandler(engine),
m_stackHandler(engine),
m_threadsHandler(engine),
m_watchHandler(engine),
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
m_disassemblerAgent(engine),
m_toolTipManager(engine)
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
{
m_logWindow = new LogWindow(m_engine); // Needed before start()
m_logWindow->setObjectName(QLatin1String(DOCKWIDGET_OUTPUT));
m_debuggerName = DebuggerEngine::tr("Debugger");
connect(action(EnableReverseDebugging), &SavedAction::valueChanged,
this, [this] { updateState(true); });
}
~DebuggerEnginePrivate()
{
destroyPerspective();
delete m_logWindow;
delete m_breakWindow;
delete m_returnWindow;
delete m_localsWindow;
delete m_watchersWindow;
delete m_inspectorWindow;
delete m_registerWindow;
delete m_modulesWindow;
delete m_sourceFilesWindow;
delete m_stackWindow;
delete m_threadsWindow;
delete m_breakView;
delete m_returnView;
delete m_localsView;
delete m_watchersView;
delete m_inspectorView;
delete m_registerView;
delete m_modulesView;
delete m_sourceFilesView;
delete m_stackView;
delete m_threadsView;
}
void setupViews();
void destroyPerspective()
{
if (!m_perspective)
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
delete m_perspective;
m_perspective = nullptr;
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
EngineManager::unregisterEngine(m_engine);
// Give up ownership on claimed breakpoints.
m_breakHandler.releaseAllBreakpoints();
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
m_toolTipManager.deregisterEngine();
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
m_memoryAgents.handleDebuggerFinished();
setBusyCursor(false);
}
void updateReturnViewHeader(int section, int, int newSize)
{
if (m_perspective && m_returnView && m_returnView->header())
m_returnView->header()->resizeSection(section, newSize);
}
void doShutdownEngine()
debugger: make location markers engine-specific
2010-12-14 12:21:29 +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
m_engine->setState(EngineShutdownRequested);
m_engine->startDying();
m_engine->showMessage("CALL: SHUTDOWN ENGINE");
m_engine->shutdownEngine();
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
}
debugger: move progress handling to debugger engine base class
2010-07-21 11:02:51 +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 doShutdownInferior()
{
m_engine->setState(InferiorShutdownRequested);
//QTC_ASSERT(isMasterEngine(), return);
resetLocation();
m_engine->showMessage("CALL: SHUTDOWN INFERIOR");
m_engine->shutdownInferior();
}
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
Debugger: Simplify queue/do pairs The functionality has been needed for asynchronous processing which are in RunWorkers nowadays, where the functionality is provided by the general RunControl framework. Change-Id: Id18f693935cd6faf5b25883dfeaace0dd691f6a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-06 08:49:36 +02:00
void doFinishDebugger()
debugger: more handler/window refactoring
2010-11-05 19:38:40 +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
QTC_ASSERT(m_state == EngineShutdownFinished, qDebug() << m_state);
QmlDebugger: fixed shutdown combined engine Task-number: QTCREATORBUG-4451 Reviewed-by: Kai Koehne
2011-04-18 16:49:41 +02:00
resetLocation();
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
m_progress.setProgressValue(1000);
m_progress.reportFinished();
m_modulesHandler.removeAll();
m_stackHandler.removeAll();
m_threadsHandler.removeAll();
m_watchHandler.cleanup();
m_engine->showMessage(tr("Debugger finished."), StatusBar);
m_engine->setState(DebuggerFinished); // Also destroys views.
debugger: more state work
2010-07-13 08:41:27 +02:00
}
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
void scheduleResetLocation()
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
{
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
m_stackHandler.scheduleResetLocation();
debugger: grey out Locals&Expressions when not accessible Change-Id: I61489b9a5bf117be154ed6899beb3f8294247c9e Reviewed-by: hjk <qthjk@ovi.com>
2012-01-17 18:44:02 +01:00
m_watchHandler.scheduleResetLocation();
debugger: fix vanishing location mark in disassembler mode Task-number: QTCREATORBUG-4157
2011-03-18 18:33:20 +01:00
m_disassemblerAgent.scheduleResetLocation();
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
m_locationTimer.setSingleShot(true);
m_locationTimer.start(80);
}
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
void resetLocation()
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
{
Debugger: Add safety net to avoid infinite lookups Do not lookup the same item twice without intermediate stepping. Dumpers could announce the existence of children but when asked for them bail out or produced similar inconsistent output. Better not depend on it. Task-number: QTCREATORBUG-15352 Change-Id: I38532d08bb438b12b6eb202a06ff610670b1069f Reviewed-by: Eike Ziller <eike.ziller@qt.io> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-04-15 15:01:12 +02:00
m_lookupRequests.clear();
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
m_locationTimer.stop();
m_locationMark.reset();
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
m_stackHandler.resetLocation();
debugger: grey out Locals&Expressions when not accessible Change-Id: I61489b9a5bf117be154ed6899beb3f8294247c9e Reviewed-by: hjk <qthjk@ovi.com>
2012-01-17 18:44:02 +01:00
m_watchHandler.resetLocation();
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
m_disassemblerAgent.resetLocation();
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
m_toolTipManager.resetLocation();
debugger: make location markers engine-specific
2010-12-14 12:21:29 +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
void handleOperateByInstructionTriggered(bool on)
{
// Go to source only if we have the file.
// if (DebuggerEngine *cppEngine = m_engine->cppEngine()) {
if (m_stackHandler.currentIndex() >= 0) {
const StackFrame frame = m_stackHandler.currentFrame();
if (on || frame.isUsable())
m_engine->gotoLocation(Location(frame, true));
}
// }
}
bool operatesByInstruction() const
{
return m_operateByInstructionAction.isChecked();
}
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
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
void setInitialActionStates();
void setBusyCursor(bool on);
void cleanupViews();
void updateState(bool alsoUpdateCompanion);
void updateReverseActions();
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: Remove some uses of semi-global currentEngine() Make use of recent TreeModel improvements in various tool views, push more operations into the engine- owned data models, specifically context menu creation. Change-Id: I479c97102b9fb81611c6461c6df1cec59295179a Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2016-07-18 12:36:31 +02:00
DebuggerEngine *m_engine = nullptr; // Not owned.
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 m_runId;
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
QPointer<RunConfiguration> m_runConfiguration; // Not owned.
QString m_debuggerName;
Perspective *m_perspective = nullptr;
DebuggerRunParameters m_runParameters;
IDevice::ConstPtr m_device;
QPointer<DebuggerEngine> m_companionEngine;
bool m_isPrimaryEngine = true;
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: 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
// The current state.
Debugger: Remove some uses of semi-global currentEngine() Make use of recent TreeModel improvements in various tool views, push more operations into the engine- owned data models, specifically context menu creation. Change-Id: I479c97102b9fb81611c6461c6df1cec59295179a Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: hjk <hjk@qt.io>
2016-07-18 12:36:31 +02:00
DebuggerState m_state = DebuggerNotReady;
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 external terminal into separate RunWorker Change-Id: Ifb9701f840195ba90db48a0f6fa07b28e0409648 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-09-27 08:22:02 +02:00
// Terminal m_terminal;
Debugger: Use Utils::ProcessHandle for DebuggerEngine::m_inferiorPid That's the intended "typesafe" use. Change-Id: Ib288fe87a47bd9484bda83e05406f0d22989b3c2 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-02-27 13:30:08 +01:00
ProcessHandle m_inferiorPid;
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
BreakHandler m_breakHandler;
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
ModulesHandler m_modulesHandler;
RegisterHandler m_registerHandler;
SourceFilesHandler m_sourceFilesHandler;
StackHandler m_stackHandler;
ThreadsHandler m_threadsHandler;
WatchHandler m_watchHandler;
debugger: move progress handling to debugger engine base class
2010-07-21 11:02:51 +02:00
QFutureInterface<void> m_progress;
Qml Debugger: Enable debugging qml+cpp standalone applications A new debugger engine, QmlCppEngine, is introduced, which wraps gdb and qml engines into one. Alternatively, if using Windows, Cdb is used instead of Gdb. Most of the debugger ui switcher is now rewritten, and it is tailored for the QML and CPP layout case, the only one supported anyway. Reviewed-by: hjk
2010-08-18 13:54:12 +02:00
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
DisassemblerAgent m_disassemblerAgent;
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
MemoryAgentSet m_memoryAgents;
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
QScopedPointer<LocationMark> m_locationMark;
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
QTimer m_locationTimer;
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
ScriptConsole: Show File and Line Info Show File and Line Info for items that have the info. Clicking on the item opens the file and sets the cursor position on the line. The context menu also provides option to copy contents and option to clear the view. Change-Id: I161de392ba35e37d323b049371619b01c617c798 Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
2012-02-22 11:50:05 +01:00
Utils::FileInProjectFinder m_fileFinder;
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 m_qtNamespace;
Debugger: Add safety net to avoid infinite lookups Do not lookup the same item twice without intermediate stepping. Dumpers could announce the existence of children but when asked for them bail out or produced similar inconsistent output. Better not depend on it. Task-number: QTCREATORBUG-15352 Change-Id: I38532d08bb438b12b6eb202a06ff610670b1069f Reviewed-by: Eike Ziller <eike.ziller@qt.io> Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2016-04-15 15:01:12 +02:00
// Safety net to avoid infinite lookups.
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
QSet<QString> m_lookupRequests; // FIXME: Integrate properly.
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
QPointer<QWidget> m_alertBox;
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
QPointer<BaseTreeView> m_breakView;
QPointer<BaseTreeView> m_returnView;
QPointer<BaseTreeView> m_localsView;
QPointer<BaseTreeView> m_watchersView;
QPointer<WatchTreeView> m_inspectorView;
QPointer<BaseTreeView> m_registerView;
QPointer<BaseTreeView> m_modulesView;
QPointer<BaseTreeView> m_sourceFilesView;
QPointer<BaseTreeView> m_stackView;
QPointer<BaseTreeView> m_threadsView;
QPointer<QWidget> m_breakWindow;
QPointer<QWidget> m_returnWindow;
QPointer<QWidget> m_localsWindow;
QPointer<QWidget> m_watchersWindow;
QPointer<QWidget> m_inspectorWindow;
QPointer<QWidget> m_registerWindow;
QPointer<QWidget> m_modulesWindow;
QPointer<QWidget> m_sourceFilesWindow;
QPointer<QWidget> m_stackWindow;
QPointer<QWidget> m_threadsWindow;
QPointer<LogWindow> m_logWindow;
QPointer<LocalsAndInspectorWindow> m_localsAndInspectorWindow;
QPointer<QLabel> m_threadLabel;
bool m_busy = false;
bool m_isDying = false;
QAction m_debugWithoutDeployAction;
QAction m_attachToQmlPortAction;
QAction m_attachToRemoteServerAction;
QAction m_startRemoteCdbAction;
QAction m_attachToCoreAction;
QAction m_detachAction;
OptionalAction m_continueAction{tr("Continue")};
QAction m_exitAction{tr("Stop Debugger")}; // On application output button if "Stop" is possible
OptionalAction m_interruptAction{tr("Interrupt")}; // On the fat debug button if "Pause" is possible
QAction m_abortAction{tr("Abort Debugging")};
QAction m_stepIntoAction{tr("Step Into")};
QAction m_stepOutAction{tr("Step Out")};
QAction m_runToLineAction{tr("Run to Line")}; // In the debug menu
QAction m_runToSelectedFunctionAction{tr("Run to Selected Function")};
QAction m_jumpToLineAction{tr("Jump to Line")};
// In the Debug menu.
QAction m_returnFromFunctionAction{tr("Immediately Return From Inner Function")};
QAction m_stepOverAction{tr("Step Over")};
QAction m_watchAction{tr("Add Expression Evaluator")};
QAction m_breakAction{tr("Toggle Breakpoint")};
QAction m_resetAction{tr("Restart Debugging")};
OptionalAction m_operateByInstructionAction{tr("Operate by Instruction")};
QAction m_recordForReverseOperationAction{tr("Record information to allpow reversal of Direction")};
OptionalAction m_operateInReverseDirectionAction{tr("Reverse Direction")};
OptionalAction m_snapshotAction{tr("Take Snapshot of Process State")};
QPointer<TerminalRunner> m_terminalRunner;
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
DebuggerToolTipManager m_toolTipManager;
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 DebuggerEnginePrivate::setupViews()
{
Debugger: Fix switch from and to sub-perspectives Change-Id: I17d3b7eb6416843b7a330da14528f0670cd88452 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-22 13:08:49 +02:00
const DebuggerRunParameters &rp = m_runParameters;
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
QTC_CHECK(!m_perspective);
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
m_perspective = new Perspective("Debugger.Perspective." + m_runId,
m_engine->displayName(),
Debugger::Constants::PRESET_PERSPECTIVE_ID,
m_debuggerName);
m_perspective->setShouldPersistChecker([this] {
return EngineManager::isLastOf(m_debuggerName);
});
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
m_progress.setProgressRange(0, 1000);
FutureProgress *fp = ProgressManager::addTask(m_progress.future(),
tr("Launching Debugger"), "Debugger.Launcher");
connect(fp, &FutureProgress::canceled, m_engine, &DebuggerEngine::quitDebugger);
fp->setKeepOnFinish(FutureProgress::HideOnFinish);
m_progress.reportStarted();
m_inferiorPid = rp.attachPID.isValid() ? rp.attachPID : ProcessHandle();
// if (m_inferiorPid.isValid())
// m_runControl->setApplicationProcessHandle(m_inferiorPid);
m_operateByInstructionAction.setEnabled(true);
m_operateByInstructionAction.setVisible(m_engine->hasCapability(DisassemblerCapability));
m_operateByInstructionAction.setIcon(Debugger::Icons::SINGLE_INSTRUCTION_MODE.icon());
m_operateByInstructionAction.setCheckable(true);
m_operateByInstructionAction.setChecked(boolSetting(OperateByInstruction));
connect(&m_operateByInstructionAction, &QAction::triggered,
this, &DebuggerEnginePrivate::handleOperateByInstructionTriggered);
QTC_ASSERT(m_state == DebuggerNotReady || m_state == DebuggerFinished, qDebug() << m_state);
m_progress.setProgressValue(200);
// m_terminal.setup();
// if (m_terminal.isUsable()) {
// connect(&m_terminal, &Terminal::stdOutReady, [this](const QString &msg) {
// m_engine->showMessage(msg, Utils::StdOutFormatSameLine);
// });
// connect(&m_terminal, &Terminal::stdErrReady, [this](const QString &msg) {
// m_engine->showMessage(msg, Utils::StdErrFormatSameLine);
// });
// connect(&m_terminal, &Terminal::error, [this](const QString &msg) {
// m_engine->showMessage(msg, Utils::ErrorMessageFormat);
// });
// }
connect(&m_locationTimer, &QTimer::timeout,
this, &DebuggerEnginePrivate::resetLocation);
QSettings *settings = ICore::settings();
Debugger: Fix switch from and to sub-perspectives Change-Id: I17d3b7eb6416843b7a330da14528f0670cd88452 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-22 13:08:49 +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
m_modulesView = new BaseTreeView;
m_modulesView->setModel(m_modulesHandler.model());
m_modulesView->setSortingEnabled(true);
m_modulesView->setSettings(settings, "Debugger.ModulesView");
connect(m_modulesView, &BaseTreeView::aboutToShow,
m_engine, &DebuggerEngine::reloadModules,
Qt::QueuedConnection);
m_modulesWindow = addSearch(m_modulesView);
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
m_modulesWindow->setObjectName(DOCKWIDGET_MODULES);
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
m_modulesWindow->setWindowTitle(tr("&Modules"));
m_registerView = new BaseTreeView;
m_registerView->setModel(m_registerHandler.model());
m_registerView->setRootIsDecorated(true);
m_registerView->setSettings(settings, "Debugger.RegisterView");
connect(m_registerView, &BaseTreeView::aboutToShow,
m_engine, &DebuggerEngine::reloadRegisters,
Qt::QueuedConnection);
m_registerWindow = addSearch(m_registerView);
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
m_registerWindow->setObjectName(DOCKWIDGET_REGISTER);
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
m_registerWindow->setWindowTitle(tr("Reg&isters"));
m_stackView = new BaseTreeView;
m_stackView->setModel(m_stackHandler.model());
m_stackView->setSettings(settings, "Debugger.StackView");
m_stackView->setIconSize(QSize(10, 10));
m_stackWindow = addSearch(m_stackView);
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
m_stackWindow->setObjectName(DOCKWIDGET_STACK);
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
m_stackWindow->setWindowTitle(tr("&Stack"));
m_sourceFilesView = new BaseTreeView;
m_sourceFilesView->setModel(m_sourceFilesHandler.model());
m_sourceFilesView->setSortingEnabled(true);
m_sourceFilesView->setSettings(settings, "Debugger.SourceFilesView");
connect(m_sourceFilesView, &BaseTreeView::aboutToShow,
m_engine, &DebuggerEngine::reloadSourceFiles,
Qt::QueuedConnection);
m_sourceFilesWindow = addSearch(m_sourceFilesView);
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
m_sourceFilesWindow->setObjectName(DOCKWIDGET_SOURCE_FILES);
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
m_sourceFilesWindow->setWindowTitle(tr("Source Files"));
m_threadsView = new BaseTreeView;
m_threadsView->setModel(m_threadsHandler.model());
m_threadsView->setSortingEnabled(true);
m_threadsView->setSettings(settings, "Debugger.ThreadsView");
m_threadsView->setIconSize(QSize(10, 10));
m_threadsWindow = addSearch(m_threadsView);
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
m_threadsWindow->setObjectName(DOCKWIDGET_THREADS);
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
m_threadsWindow->setWindowTitle(tr("&Threads"));
m_returnView = new WatchTreeView{ReturnType};
m_returnView->setModel(m_watchHandler.model());
m_returnWindow = addSearch(m_returnView);
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
m_returnWindow->setObjectName("CppDebugReturn");
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
m_returnWindow->setWindowTitle(tr("Locals"));
m_returnWindow->setVisible(false);
m_localsView = new WatchTreeView{LocalsType};
m_localsView->setModel(m_watchHandler.model());
m_localsView->setSettings(settings, "Debugger.LocalsView");
m_localsWindow = addSearch(m_localsView);
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
m_localsWindow->setObjectName("CppDebugLocals");
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
m_localsWindow->setWindowTitle(tr("Locals"));
m_inspectorView = new WatchTreeView{InspectType};
m_inspectorView->setModel(m_watchHandler.model());
m_inspectorView->setSettings(settings, "Debugger.LocalsView"); // sic! same as locals view.
m_inspectorWindow = addSearch(m_inspectorView);
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
m_inspectorWindow->setObjectName("Inspector");
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
m_inspectorWindow->setWindowTitle(tr("Locals"));
m_watchersView = new WatchTreeView{WatchersType};
m_watchersView->setModel(m_watchHandler.model());
m_watchersView->setSettings(settings, "Debugger.WatchersView");
m_watchersWindow = addSearch(m_watchersView);
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
m_watchersWindow->setObjectName("CppDebugWatchers");
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
m_watchersWindow->setWindowTitle(tr("&Expressions"));
m_localsAndInspectorWindow = new LocalsAndInspectorWindow(
m_localsWindow, m_inspectorWindow, m_returnWindow);
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
m_localsAndInspectorWindow->setObjectName(DOCKWIDGET_LOCALS_AND_INSPECTOR);
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
m_localsAndInspectorWindow->setWindowTitle(m_localsWindow->windowTitle());
// Locals
connect(m_localsView->header(), &QHeaderView::sectionResized,
this, &DebuggerEnginePrivate::updateReturnViewHeader, Qt::QueuedConnection);
m_breakView = new BaseTreeView;
m_breakView->setIconSize(QSize(10, 10));
m_breakView->setWindowIcon(Icons::BREAKPOINTS.icon());
m_breakView->setSelectionMode(QAbstractItemView::ExtendedSelection);
connect(action(UseAddressInBreakpointsView), &QAction::toggled,
this, [this](bool on) { m_breakView->setColumnHidden(BreakpointAddressColumn, !on); });
m_breakView->setSettings(settings, "Debugger.BreakWindow");
m_breakView->setModel(m_breakHandler.model());
m_breakView->setRootIsDecorated(true);
m_breakWindow = addSearch(m_breakView);
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
m_breakWindow->setObjectName(DOCKWIDGET_BREAK);
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
m_breakWindow->setWindowTitle(tr("&Breakpoints"));
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
m_perspective->addToolBarSwitcher(EngineManager::engineChooser(), 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
m_perspective->addToolBarAction(&m_continueAction);
m_perspective->addToolBarAction(&m_interruptAction);
m_perspective->addToolBarAction(&m_exitAction);
m_perspective->addToolBarAction(&m_stepOverAction);
m_perspective->addToolBarAction(&m_stepIntoAction);
m_perspective->addToolBarAction(&m_stepOutAction);
m_perspective->addToolBarAction(&m_resetAction);
m_perspective->addToolBarAction(&m_operateByInstructionAction);
m_continueAction.setIcon(Icons::DEBUG_CONTINUE_SMALL_TOOLBAR.icon());
connect(&m_continueAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecContinue);
m_exitAction.setIcon(Icons::DEBUG_EXIT_SMALL.icon());
connect(&m_exitAction, &QAction::triggered,
m_engine, &DebuggerEngine::requestRunControlStop);
m_interruptAction.setIcon(Icons::DEBUG_INTERRUPT_SMALL_TOOLBAR.icon());
connect(&m_interruptAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecInterrupt);
m_abortAction.setToolTip(tr("Aborts debugging and resets the debugger to the initial state."));
connect(&m_abortAction, &QAction::triggered,
m_engine, &DebuggerEngine::abortDebugger);
m_resetAction.setToolTip(tr("Restart the debugging session."));
m_resetAction.setIcon(Icons::RESTART_TOOLBAR.icon());
connect(&m_resetAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleReset);
m_stepOverAction.setIcon(Icons::STEP_OVER_TOOLBAR.icon());
connect(&m_stepOverAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecNext);
m_stepIntoAction.setIcon(Icons::STEP_INTO_TOOLBAR.icon());
connect(&m_stepIntoAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecStep);
m_stepOutAction.setIcon(Icons::STEP_OUT_TOOLBAR.icon());
connect(&m_stepOutAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecStepOut);
connect(&m_runToLineAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecRunToLine);
connect(&m_runToSelectedFunctionAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecRunToSelectedFunction);
connect(&m_returnFromFunctionAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecReturn);
connect(&m_jumpToLineAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleExecJumpToLine);
m_perspective->addToolBarAction(&m_recordForReverseOperationAction);
connect(&m_recordForReverseOperationAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleRecordReverse);
m_perspective->addToolBarAction(&m_operateInReverseDirectionAction);
connect(&m_operateInReverseDirectionAction, &QAction::triggered,
m_engine, &DebuggerEngine::handleReverseDirection);
m_perspective->addToolBarAction(&m_snapshotAction);
connect(&m_snapshotAction, &QAction::triggered,
m_engine, &DebuggerEngine::createSnapshot);
m_perspective->addToolbarSeparator();
m_threadLabel = new QLabel(tr("Threads:"));
m_perspective->addToolBarWidget(m_threadLabel);
Debugger: Simplify thread switching more This moves the thread switcher combobox, the only consumer of part of the threadhandler interface, into the threadhandler. Change-Id: Icafd72e7777fad9196ce8fb33a79cae26c29a521 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-31 18:30:14 +02:00
m_perspective->addToolBarWidget(m_threadsHandler.threadSwitcher());
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
connect(TextEditorSettings::instance(), &TextEditorSettings::fontSettingsChanged,
this, [this](const FontSettings &settings) {
if (!boolSetting(FontSizeFollowsEditor))
return;
const qreal size = settings.fontZoom() * settings.fontSize() / 100.;
QFont font = m_breakWindow->font();
font.setPointSizeF(size);
m_breakWindow->setFont(font);
m_logWindow->setFont(font);
m_localsWindow->setFont(font);
m_modulesWindow->setFont(font);
//m_consoleWindow->setFont(font);
m_registerWindow->setFont(font);
m_returnWindow->setFont(font);
m_sourceFilesWindow->setFont(font);
m_stackWindow->setFont(font);
m_threadsWindow->setFont(font);
m_watchersWindow->setFont(font);
m_inspectorWindow->setFont(font);
});
m_perspective->addWindow(m_stackWindow, Perspective::SplitVertical, nullptr);
m_perspective->addWindow(m_breakWindow, Perspective::SplitHorizontal, m_stackWindow);
m_perspective->addWindow(m_threadsWindow, Perspective::AddToTab, m_breakWindow,false);
m_perspective->addWindow(m_modulesWindow, Perspective::AddToTab, m_threadsWindow, false);
m_perspective->addWindow(m_sourceFilesWindow, Perspective::AddToTab, m_modulesWindow, false);
m_perspective->addWindow(m_localsAndInspectorWindow, Perspective::AddToTab, nullptr, true, Qt::RightDockWidgetArea);
m_perspective->addWindow(m_watchersWindow, Perspective::AddToTab, m_localsAndInspectorWindow, true, Qt::RightDockWidgetArea);
m_perspective->addWindow(m_registerWindow, Perspective::AddToTab, m_watchersWindow, true, Qt::RightDockWidgetArea);
m_perspective->addWindow(m_logWindow, Perspective::AddToTab, nullptr, false, Qt::TopDockWidgetArea);
m_perspective->select();
}
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
//////////////////////////////////////////////////////////////////////
//
// DebuggerEngine
//
//////////////////////////////////////////////////////////////////////
Debugger: Move run parameters from engine to tool runner The parameters belong to the run control, they should not be triplicated in case of a combined engine. Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-05 14:45:36 +02:00
DebuggerEngine::DebuggerEngine()
: d(new DebuggerEnginePrivate(this))
{
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
updateState(false);
Debugger: Move run parameters from engine to tool runner The parameters belong to the run control, they should not be triplicated in case of a combined engine. Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-05 14:45:36 +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
DebuggerEngine::~DebuggerEngine()
{
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
// EngineManager::unregisterEngine(this);
debugger: delete debugger engine's private data
2010-07-20 10:04:08 +02:00
delete d;
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 DebuggerEngine::setDebuggerName(const QString &name)
{
d->m_debuggerName = name;
}
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 DebuggerEngine::debuggerName() const
{
return d->m_debuggerName;
}
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 DebuggerEngine::stateName(int s)
debugger move DebuggerStartParameters into file of its own
2011-01-07 09:44:23 +01: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
# define SN(x) case x: return QLatin1String(#x);
debugger move DebuggerStartParameters into file of its own
2011-01-07 09:44:23 +01:00
switch (s) {
SN(DebuggerNotReady)
SN(EngineSetupRequested)
SN(EngineSetupOk)
SN(EngineSetupFailed)
SN(EngineRunFailed)
SN(EngineRunRequested)
SN(InferiorRunRequested)
SN(InferiorRunOk)
SN(InferiorRunFailed)
SN(InferiorUnrunnable)
SN(InferiorStopRequested)
SN(InferiorStopOk)
SN(InferiorStopFailed)
SN(InferiorShutdownRequested)
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
SN(InferiorShutdownFinished)
debugger move DebuggerStartParameters into file of its own
2011-01-07 09:44:23 +01:00
SN(EngineShutdownRequested)
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
SN(EngineShutdownFinished)
debugger move DebuggerStartParameters into file of its own
2011-01-07 09:44:23 +01:00
SN(DebuggerFinished)
}
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
return QLatin1String("<unknown>");
debugger move DebuggerStartParameters into file of its own
2011-01-07 09:44:23 +01:00
# undef SN
}
debugger: more breakpoint management related fixes
2010-06-22 15:37:27 +02:00
void DebuggerEngine::showStatusMessage(const QString &msg, int timeout) 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: more breakpoint management related fixes
2010-06-22 15:37:27 +02:00
showMessage(msg, StatusBar, timeout);
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: more breakpoint management related fixes
2010-06-22 15:37:27 +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 DebuggerEngine::updateLocalsWindow(bool showReturn)
{
d->m_returnWindow->setVisible(showReturn);
d->m_localsView->resizeColumns();
}
bool DebuggerEngine::isRegistersWindowVisible() const
{
return d->m_registerWindow->isVisible();
}
bool DebuggerEngine::isModulesWindowVisible() const
{
return d->m_modulesWindow->isVisible();
}
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
void DebuggerEngine::frameUp()
{
int currentIndex = stackHandler()->currentIndex();
activateFrame(qMin(currentIndex + 1, stackHandler()->stackSize() - 1));
}
void DebuggerEngine::frameDown()
{
int currentIndex = stackHandler()->currentIndex();
activateFrame(qMax(currentIndex - 1, 0));
}
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
void DebuggerEngine::doUpdateLocals(const UpdateParameters &)
{
}
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
ModulesHandler *DebuggerEngine::modulesHandler() 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
return &d->m_modulesHandler;
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
}
RegisterHandler *DebuggerEngine::registerHandler() 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
return &d->m_registerHandler;
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
}
StackHandler *DebuggerEngine::stackHandler() 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
return &d->m_stackHandler;
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
}
ThreadsHandler *DebuggerEngine::threadsHandler() 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
return &d->m_threadsHandler;
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
}
WatchHandler *DebuggerEngine::watchHandler() 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
return &d->m_watchHandler;
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
}
SourceFilesHandler *DebuggerEngine::sourceFilesHandler() 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
return &d->m_sourceFilesHandler;
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
BreakHandler *DebuggerEngine::breakHandler() const
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
{
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
return &d->m_breakHandler;
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
LogWindow *DebuggerEngine::logWindow() const
debugger: rework WatchModel It's one model for all locals, watch, return, tooltip and inspector data. This allows more streamlined code paths and better isolation of the model data from the WatchHandler. WatchItems are now registered in a hash indexed by iname, so inames can be used as the primary handle to watch data in the WatchHandler interface. Change-Id: Idac0a808b5d785307496d1de4198a1f2e9ce3880 Reviewed-by: Aurindam Jana <aurindam.jana@nokia.com>
2012-05-18 02:28:41 +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
return d->m_logWindow;
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
}
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
DisassemblerAgent *DebuggerEngine::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: 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
return &d->m_disassemblerAgent;
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/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
void DebuggerEngine::fetchMemory(MemoryAgent *, quint64 addr, quint64 length)
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_UNUSED(addr);
Q_UNUSED(length);
}
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
void DebuggerEngine::changeMemory(MemoryAgent *, quint64 addr, const QByteArray &data)
debugger: work on writable memory view
2011-02-25 13:21:54 +01:00
{
Q_UNUSED(addr);
Q_UNUSED(data);
}
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
void DebuggerEngine::setRegisterValue(const QString &name, const QString &value)
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
{
Debugger: 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
Q_UNUSED(name);
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_UNUSED(value);
}
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 DebuggerEngine::setRunParameters(const DebuggerRunParameters &runParameters)
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
d->m_runParameters = runParameters;
Debugger et al: Move code from DebuggerRunControl to DebuggerRunTool It's tool specific, so put it into the tool (only) related code. The additional level of indirection will go again, plus the original one will be removed once the *DebugSupport classes can directly use DebuggerRunTool as base. Change-Id: Ieaa386a0f7d724b09cedaaba8fb7d1e6dc4ad55b Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-04-21 17:20:57 +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 DebuggerEngine::setRunId(const QString &id)
{
d->m_runId = id;
}
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 DebuggerEngine::setRunTool(DebuggerRunTool *runTool)
Debugger et al: Move code from DebuggerRunControl to DebuggerRunTool It's tool specific, so put it into the tool (only) related code. The additional level of indirection will go again, plus the original one will be removed once the *DebugSupport classes can directly use DebuggerRunTool as base. Change-Id: Ieaa386a0f7d724b09cedaaba8fb7d1e6dc4ad55b Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-04-21 17:20:57 +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
RunControl *runControl = runTool->runControl();
d->m_runConfiguration = runControl->runConfiguration();
d->m_device = runControl->device();
if (!d->m_device)
d->m_device = d->m_runParameters.inferior.device;
d->m_terminalRunner = runTool->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: 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
validateExecutable();
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
d->setupViews();
}
Debugger: Introduce a pty based channel to inferiors This is experimental for now and requires QTC_USE_PTY=1 in the environment to be used. Change-Id: I460ce7b9283467d481e903f731f4243b7e5ec094 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-01-14 16:58:10 +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
void DebuggerEngine::start()
{
EngineManager::registerEngine(this);
d->m_watchHandler.resetWatchers();
d->setInitialActionStates();
Debugger: Synchronize slave engine inferior setup phases again This reverts most of 4977c915 and applies the same pattern for setupEngine. Turns out that the removal was premature due to the special needs of Android setup. Task-number: QTCREATORBUG-19199 Change-Id: I4e2ff4f34a842f3296999a0651e7e8fd6470198c Reviewed-by: Vikas Pachdha <vikas.pachdha@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-11-06 17:19:35 +01:00
setState(EngineSetupRequested);
showMessage("CALL: SETUP ENGINE");
setupEngine();
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
}
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
void DebuggerEngine::resetLocation()
{
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
// Do it after some delay to avoid flicker.
d->scheduleResetLocation();
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: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
void DebuggerEngine::gotoLocation(const Location &loc)
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: Reset Location Mark Call resetLocation() before setLocation(). Change-Id: I633d513ddc9a5a1683e81f7cabf127e79885ad4e Reviewed-by: hjk <qthjk@ovi.com>
2011-12-28 13:20:27 +01:00
d->resetLocation();
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
if (loc.canBeDisassembled()
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
&& ((hasCapability(OperateByInstructionCapability) && d->operatesByInstruction())
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
|| !loc.hasDebugInfo()) )
{
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
d->m_disassemblerAgent.setLocation(loc);
return;
}
debugger: make location markers engine-specific
2010-12-14 12:21:29 +01:00
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
if (loc.fileName().isEmpty()) {
Debugger: Clean up debuggerengine.cpp Some leftover stringfreeze workaround, plus QLatin1*. Change-Id: I5e143af5cda64cb29b7769174187fc86185a89cb Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2016-06-27 16:40:23 +02:00
showMessage("CANNOT GO TO THIS LOCATION");
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
return;
}
lldb: Quick fix for weird behavior when opening locations from debugger Paths passed to Qt Creator API must be cleaned. Make sure that the file path that is opened from stack view and when stepping etc, is cleaned. Task-number: QTCREATORBUG-10119 Change-Id: Iaac9b15e76cf8dff514889f201c4f65330145d16 Reviewed-by: hjk <hjk121@nokiamail.com>
2013-10-17 17:25:05 +02:00
const QString file = QDir::cleanPath(loc.fileName());
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
const int line = loc.lineNumber();
Work with documents instead of editors where possible in debugger And where using editors is necessary, take *all* editors into account, not a random set of what previously was called "original" editors (when using splits). Change-Id: Id6bbad08f3083b6744fc2edcf0b87ba504d3257b Reviewed-by: hjk <hjk121@nokiamail.com>
2013-07-09 12:14:33 +02:00
bool newEditor = false;
Debugger: Do not switch to design mode when hitting a break point Change-Id: I2b31aa78a707ca830382095f20d33439caa830ac Task-number: QTCREATORBUG-20712 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: Eike Ziller <eike.ziller@qt.io>
2018-07-02 15:19:54 +02:00
IEditor *editor = EditorManager::openEditor(
file, Id(),
EditorManager::IgnoreNavigationHistory | EditorManager::DoNotSwitchToDesignMode,
&newEditor);
Work with documents instead of editors where possible in debugger And where using editors is necessary, take *all* editors into account, not a random set of what previously was called "original" editors (when using splits). Change-Id: Id6bbad08f3083b6744fc2edcf0b87ba504d3257b Reviewed-by: hjk <hjk121@nokiamail.com>
2013-07-09 12:14:33 +02:00
QTC_ASSERT(editor, return); // Unreadable file?
Adds option to make editor not scroll on debugging Added an option to change the behavior of the debuggercore so that the current editor isn't always centered on the current line, to stop unnecessary jumping of the code. Change-Id: I9406df518bb1b977e39a0265ee7fd6fae2069ed9 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-05-02 12:08:44 +02:00
Debugger: Reduce line noise Move some function out of the DebuggerCore "namespace", to avoid one indirection and removes clutter in the calling code. Change-Id: I1c870d5c7eeade32fa63dedf581490fbb090cd6a Reviewed-by: Christian Stenger <christian.stenger@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-07-28 14:23:52 +02:00
editor->gotoLine(line, 0, !boolSetting(StationaryEditorWhileStepping));
Adds option to make editor not scroll on debugging Added an option to change the behavior of the debuggercore so that the current editor isn't always centered on the current line, to stop unnecessary jumping of the code. Change-Id: I9406df518bb1b977e39a0265ee7fd6fae2069ed9 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-05-02 12:08:44 +02:00
Work with documents instead of editors where possible in debugger And where using editors is necessary, take *all* editors into account, not a random set of what previously was called "original" editors (when using splits). Change-Id: Id6bbad08f3083b6744fc2edcf0b87ba504d3257b Reviewed-by: hjk <hjk121@nokiamail.com>
2013-07-09 12:14:33 +02:00
if (newEditor)
editor->document()->setProperty(Constants::OPENED_BY_DEBUGGER, true);
debugger: make memory view updatable Still some flickering and no marks which parts changed.
2010-12-14 16:01:02 +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
if (loc.needsMarker()) {
Use FileName in TextMark Change-Id: I3666d95dc8ef3b7da099d6d30f5cb4678a349493 Reviewed-by: David Schulz <david.schulz@qt.io>
2018-05-02 15:02:00 +02:00
d->m_locationMark.reset(new LocationMark(this, FileName::fromString(file), line));
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
d->m_locationMark->setToolTip(tr("Current debugger location of %1").arg(displayName()));
}
}
void DebuggerEngine::gotoCurrentLocation()
{
int top = stackHandler()->currentIndex();
if (top >= 0)
gotoLocation(stackHandler()->currentFrame());
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: 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
const DebuggerRunParameters &DebuggerEngine::runParameters() 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: 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
return d->m_runParameters;
}
DebuggerRunParameters &DebuggerEngine::mutableRunParameters() const
{
return d->m_runParameters;
}
IDevice::ConstPtr DebuggerEngine::device() const
{
return d->m_device;
}
DebuggerEngine *DebuggerEngine::companionEngine() const
{
return d->m_companionEngine;
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 DebuggerEngine::state() const
{
return d->m_state;
}
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 DebuggerEngine::abortDebugger()
{
resetLocation();
if (!d->m_isDying) {
// Be friendly the first time. This will change targetState().
showMessage("ABORTING DEBUGGER. FIRST TIME.");
quitDebugger();
} else {
// We already tried. Try harder.
showMessage("ABORTING DEBUGGER. SECOND TIME.");
abortDebuggerProcess();
emit requestRunControlFinish();
}
}
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
static bool isAllowedTransition(DebuggerState from, DebuggerState to)
{
switch (from) {
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
case DebuggerNotReady:
debugger: adjust pdb engine to state machine changes
2010-07-12 15:34:05 +02:00
return to == EngineSetupRequested;
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: 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
case EngineSetupRequested:
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
return to == EngineSetupOk || to == EngineSetupFailed;
case EngineSetupFailed:
debugger: fix/clarify intention of the EngineSetupFailed state.
2010-11-10 12:53:33 +01:00
// In is the engine's task to go into a proper "Shutdown"
// state before calling notifyEngineSetupFailed
return to == DebuggerFinished;
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
case EngineSetupOk:
Debugger: Merge EngineSetup and InferiorSetup start phases It was needed in the past to trigger e.g. gdbserver setup in remote cases which is nowadays handled by separate RunWorkers. Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-11-15 17:12:03 +01:00
return to == EngineRunRequested || to == EngineShutdownRequested;
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
case EngineRunRequested:
debugger: remove EngineRunOk state again
2011-01-14 18:47:44 +01:00
return to == EngineRunFailed
debugger: use *running instead of ^running as running notification. This is closer to internal gdb state. There are still a few workarounds for gdb < 7.0 which probably should be dropped as BFD 2.18.50.20080226 yields "assertion fail elf32-i386.c:366" on stock Ubuntu 12.04 gcc, so stock gdb 6.8 cannot be used with that compiler anyways. Change-Id: I22c4e0ce91f634cc171d65f0ad07d68d679af10c Reviewed-by: David Schulz <david.schulz@nokia.com> Reviewed-by: hjk <qthjk@ovi.com>
2012-08-21 11:30:59 +02:00
|| to == InferiorRunRequested
debugger: remove EngineRunOk state again
2011-01-14 18:47:44 +01:00
|| to == InferiorRunOk
|| to == InferiorStopOk
|| to == InferiorUnrunnable;
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
case EngineRunFailed:
DebuggerEngine: fix shutdown when run failed Reviewed-by: hjk
2010-11-29 17:12:43 +01:00
return to == EngineShutdownRequested;
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
case InferiorRunRequested:
return to == InferiorRunOk || to == InferiorRunFailed;
case InferiorRunFailed:
return to == InferiorStopOk;
case InferiorRunOk:
debugger: remove InferiorStopSpontaneous state again
2011-01-14 19:04:16 +01:00
return to == InferiorStopRequested
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
|| to == InferiorStopOk // A spontaneous stop.
|| to == InferiorShutdownFinished; // A spontaneous exit.
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
case InferiorStopRequested:
return to == InferiorStopOk || to == InferiorStopFailed;
case InferiorStopOk:
return to == InferiorRunRequested || to == InferiorShutdownRequested
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
|| to == InferiorStopOk || to == InferiorShutdownFinished;
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
case InferiorStopFailed:
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
return to == EngineShutdownRequested;
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
case InferiorUnrunnable:
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
return to == InferiorShutdownRequested;
case InferiorShutdownRequested:
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
return to == InferiorShutdownFinished;
case InferiorShutdownFinished:
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
return to == EngineShutdownRequested;
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: 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
case EngineShutdownRequested:
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
return to == EngineShutdownFinished;
case EngineShutdownFinished:
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
return to == DebuggerFinished;
case DebuggerFinished:
debugger: make debugger restartable using the buttons in the application output pane
2010-07-20 18:31:35 +02:00
return to == EngineSetupRequested; // Happens on restart.
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: start tightening the breakpoint state machinery
2010-11-16 13:52:21 +01:00
qDebug() << "UNKNOWN DEBUGGER STATE:" << from;
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
return false;
}
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
void DebuggerEngine::notifyEngineSetupFailed()
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
showMessage("NOTE: ENGINE SETUP FAILED");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineSetupRequested, qDebug() << this << state());
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
setState(EngineSetupFailed);
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
if (d->m_isPrimaryEngine) {
Debugger: Move some code around Parts of the Debugger engine rampdown mechanisms are essentially one code path now, don't distribute that over four classes. Change-Id: I4c6edbc0db94d1f658b0c1d9c154552f286db876 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-19 14:18:26 +02:00
showMessage(tr("Debugging has failed"), NormalMessageFormat);
d->m_progress.setProgressValue(900);
d->m_progress.reportCanceled();
d->m_progress.reportFinished();
}
debugger: fix EngineSetupFailed path Task-number: QTCREATORBUG-2837
2010-10-26 17:08:12 +02:00
setState(DebuggerFinished);
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
}
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
void DebuggerEngine::notifyEngineSetupOk()
debugger: encapsulate part of the startup logic in the base class
2010-07-08 14:26:35 +02:00
{
Debugger: Merge EngineSetup and InferiorSetup start phases It was needed in the past to trigger e.g. gdbserver setup in remote cases which is nowadays handled by separate RunWorkers. Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-11-15 17:12:03 +01:00
//#ifdef WITH_BENCHMARK
// CALLGRIND_START_INSTRUMENTATION;
//#endif
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
showMessage("NOTE: ENGINE SETUP OK");
Debugger: Merge EngineSetup and InferiorSetup start phases It was needed in the past to trigger e.g. gdbserver setup in remote cases which is nowadays handled by separate RunWorkers. Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-11-15 17:12:03 +01:00
d->m_progress.setProgressValue(250);
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineSetupRequested, qDebug() << this << state());
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
setState(EngineSetupOk);
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
// Slaves will get called setupSlaveInferior() below.
Debugger: Merge EngineSetup and InferiorSetup start phases It was needed in the past to trigger e.g. gdbserver setup in remote cases which is nowadays handled by separate RunWorkers. Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-11-15 17:12:03 +01:00
setState(EngineRunRequested);
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
showMessage("CALL: RUN ENGINE");
Debugger: Merge EngineSetup and InferiorSetup start phases It was needed in the past to trigger e.g. gdbserver setup in remote cases which is nowadays handled by separate RunWorkers. Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-11-15 17:12:03 +01:00
d->m_progress.setProgressValue(300);
runEngine();
debugger: some start up state consolidation
2011-01-14 18:16:40 +01:00
}
Debugger: State machine cosmetics Remove one unused notification, rename notifyInferiorUnrunnable. Change-Id: I585d3a8606585fbdd8ad48e5eeecf629542bd93c Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-02-26 15:21:43 +01:00
void DebuggerEngine::notifyEngineRunOkAndInferiorUnrunnable()
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: 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
showMessage("NOTE: INFERIOR UNRUNNABLE");
debugger: improve launch progress display
2010-07-22 12:02:09 +02:00
d->m_progress.setProgressValue(1000);
d->m_progress.reportFinished();
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineRunRequested, qDebug() << this << state());
debugger: better status messages on startup and interrupt Change-Id: Id78f189bb55db618e5cbff233e4edebc2d6e886c Reviewed-by: hjk <qthjk@ovi.com>
2012-03-07 16:40:54 +01:00
showStatusMessage(tr("Loading finished."));
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
setState(InferiorUnrunnable);
}
void DebuggerEngine::notifyEngineRunFailed()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ENGINE RUN FAILED");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineRunRequested, qDebug() << this << state());
debugger: improve launch progress display
2010-07-22 12:02:09 +02:00
d->m_progress.setProgressValue(900);
d->m_progress.reportCanceled();
d->m_progress.reportFinished();
debugger: better status messages on startup and interrupt Change-Id: Id78f189bb55db618e5cbff233e4edebc2d6e886c Reviewed-by: hjk <qthjk@ovi.com>
2012-03-07 16:40:54 +01:00
showStatusMessage(tr("Run failed."));
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
setState(EngineRunFailed);
Debugger: Move master engine checks around From several places in DebuggerEngine::* to one place in DebuggerEnginePrivate. Change-Id: Ic87110a11087e338cc9a6b66ea30ea2259861d9e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-12-14 10:31:44 +01:00
d->doShutdownEngine();
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
}
void DebuggerEngine::notifyEngineRunAndInferiorRunOk()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ENGINE RUN AND INFERIOR RUN OK");
debugger: improve launch progress display
2010-07-22 12:02:09 +02:00
d->m_progress.setProgressValue(1000);
d->m_progress.reportFinished();
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineRunRequested, qDebug() << this << state());
debugger: better status messages on startup and interrupt Change-Id: Id78f189bb55db618e5cbff233e4edebc2d6e886c Reviewed-by: hjk <qthjk@ovi.com>
2012-03-07 16:40:54 +01:00
showStatusMessage(tr("Running."));
debugger: remove EngineRunOk state again
2011-01-14 18:47:44 +01:00
setState(InferiorRunOk);
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
}
void DebuggerEngine::notifyEngineRunAndInferiorStopOk()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ENGINE RUN AND INFERIOR STOP OK");
debugger: improve launch progress display
2010-07-22 12:02:09 +02:00
d->m_progress.setProgressValue(1000);
d->m_progress.reportFinished();
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineRunRequested, qDebug() << this << state());
debugger: better status messages on startup and interrupt Change-Id: Id78f189bb55db618e5cbff233e4edebc2d6e886c Reviewed-by: hjk <qthjk@ovi.com>
2012-03-07 16:40:54 +01:00
showStatusMessage(tr("Stopped."));
debugger: remove EngineRunOk state again
2011-01-14 18:47:44 +01:00
setState(InferiorStopOk);
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
}
void DebuggerEngine::notifyInferiorRunRequested()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR RUN REQUESTED");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == InferiorStopOk, qDebug() << this << state());
debugger: better status messages on startup and interrupt Change-Id: Id78f189bb55db618e5cbff233e4edebc2d6e886c Reviewed-by: hjk <qthjk@ovi.com>
2012-03-07 16:40:54 +01:00
showStatusMessage(tr("Run requested..."));
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
setState(InferiorRunRequested);
}
void DebuggerEngine::notifyInferiorRunOk()
{
debugger: use *running instead of ^running as running notification. This is closer to internal gdb state. There are still a few workarounds for gdb < 7.0 which probably should be dropped as BFD 2.18.50.20080226 yields "assertion fail elf32-i386.c:366" on stock Ubuntu 12.04 gcc, so stock gdb 6.8 cannot be used with that compiler anyways. Change-Id: I22c4e0ce91f634cc171d65f0ad07d68d679af10c Reviewed-by: David Schulz <david.schulz@nokia.com> Reviewed-by: hjk <qthjk@ovi.com>
2012-08-21 11:30:59 +02:00
if (state() == InferiorRunOk) {
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR RUN OK - REPEATED.");
debugger: use *running instead of ^running as running notification. This is closer to internal gdb state. There are still a few workarounds for gdb < 7.0 which probably should be dropped as BFD 2.18.50.20080226 yields "assertion fail elf32-i386.c:366" on stock Ubuntu 12.04 gcc, so stock gdb 6.8 cannot be used with that compiler anyways. Change-Id: I22c4e0ce91f634cc171d65f0ad07d68d679af10c Reviewed-by: David Schulz <david.schulz@nokia.com> Reviewed-by: hjk <qthjk@ovi.com>
2012-08-21 11:30:59 +02:00
return;
}
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR RUN OK");
debugger: better status messages on startup and interrupt Change-Id: Id78f189bb55db618e5cbff233e4edebc2d6e886c Reviewed-by: hjk <qthjk@ovi.com>
2012-03-07 16:40:54 +01:00
showStatusMessage(tr("Running."));
debugger: use *running instead of ^running as running notification. This is closer to internal gdb state. There are still a few workarounds for gdb < 7.0 which probably should be dropped as BFD 2.18.50.20080226 yields "assertion fail elf32-i386.c:366" on stock Ubuntu 12.04 gcc, so stock gdb 6.8 cannot be used with that compiler anyways. Change-Id: I22c4e0ce91f634cc171d65f0ad07d68d679af10c Reviewed-by: David Schulz <david.schulz@nokia.com> Reviewed-by: hjk <qthjk@ovi.com>
2012-08-21 11:30:59 +02:00
// Transition from StopRequested can happen in remotegdbadapter.
debugger: re-enable interrupting in remote setups Change-Id: I6d4503ec78e3ce590691dde69992a1599b506fc5 Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
2011-10-12 16:34:02 +02:00
QTC_ASSERT(state() == InferiorRunRequested
debugger: use *running instead of ^running as running notification. This is closer to internal gdb state. There are still a few workarounds for gdb < 7.0 which probably should be dropped as BFD 2.18.50.20080226 yields "assertion fail elf32-i386.c:366" on stock Ubuntu 12.04 gcc, so stock gdb 6.8 cannot be used with that compiler anyways. Change-Id: I22c4e0ce91f634cc171d65f0ad07d68d679af10c Reviewed-by: David Schulz <david.schulz@nokia.com> Reviewed-by: hjk <qthjk@ovi.com>
2012-08-21 11:30:59 +02:00
|| state() == InferiorStopOk
debugger: re-enable interrupting in remote setups Change-Id: I6d4503ec78e3ce590691dde69992a1599b506fc5 Reviewed-by: Christian Kandeler <christian.kandeler@nokia.com>
2011-10-12 16:34:02 +02:00
|| state() == InferiorStopRequested, qDebug() << this << state());
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
setState(InferiorRunOk);
}
void DebuggerEngine::notifyInferiorRunFailed()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR RUN FAILED");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == InferiorRunRequested, qDebug() << this << state());
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
setState(InferiorRunFailed);
setState(InferiorStopOk);
debugger: more state work
2010-07-13 08:41:27 +02:00
if (isDying())
Debugger: Simplify queue/do pairs The functionality has been needed for asynchronous processing which are in RunWorkers nowadays, where the functionality is provided by the general RunControl framework. Change-Id: Id18f693935cd6faf5b25883dfeaace0dd691f6a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-06 08:49:36 +02:00
d->doShutdownInferior();
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
}
void DebuggerEngine::notifyInferiorStopOk()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR STOP OK");
debugger: more state work
2010-07-13 08:41:27 +02:00
// Ignore spurious notifications after we are set to die.
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
if (isDying()) {
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ... WHILE DYING. ");
debugger: more state work
2010-07-13 08:41:27 +02:00
// Forward state to "StopOk" if needed.
if (state() == InferiorStopRequested
|| state() == InferiorRunRequested
|| state() == InferiorRunOk) {
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ... FORWARDING TO 'STOP OK'. ");
debugger: more state work
2010-07-13 08:41:27 +02:00
setState(InferiorStopOk);
}
Remove braces for single lines of conditions #!/usr/bin/env ruby Dir.glob('**/*.cpp') { |file| # skip ast (excluding paste, astpath, and canv'ast'imer) next if file =~ /ast[^eip]|keywords\.|qualifiers|preprocessor|names.cpp/i s = File.read(file) next if s.include?('qlalr') orig = s.dup s.gsub!(/\n *if [^\n]*{\n[^\n]*\n\s+}(\s+else if [^\n]* {\n[^\n]*\n\s+})*(\s+else {\n[^\n]*\n\s+})?\n/m) { |m| res = $& if res =~ /^\s*(\/\/|[A-Z_]{3,})/ # C++ comment or macro (Q_UNUSED, SDEBUG), do not touch braces res else res.gsub!('} else', 'else') res.gsub!(/\n +} *\n/m, "\n") res.gsub(/ *{$/, '') end } s.gsub!(/ *$/, '') File.open(file, 'wb').write(s) if s != orig } Change-Id: I3b30ee60df0986f66c02132c65fc38a3fbb6bbdc Reviewed-by: hjk <qthjk@ovi.com>
2013-01-08 03:32:53 +02:00
if (state() == InferiorStopOk || state() == InferiorStopFailed)
Debugger: Simplify queue/do pairs The functionality has been needed for asynchronous processing which are in RunWorkers nowadays, where the functionality is provided by the general RunControl framework. Change-Id: Id18f693935cd6faf5b25883dfeaace0dd691f6a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-06 08:49:36 +02:00
d->doShutdownInferior();
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ... IGNORING STOP MESSAGE");
debugger: more state work
2010-07-13 08:41:27 +02:00
return;
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: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == InferiorStopRequested, qDebug() << this << state());
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
showMessage(tr("Stopped."), StatusBar);
debugger: more state work
2010-07-13 08:41:27 +02:00
setState(InferiorStopOk);
debugger: refactor startup logic
2010-07-08 18:10:50 +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
void DebuggerEngine::notifyInferiorSpontaneousStop()
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR SPONTANEOUS STOP");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == InferiorRunOk, qDebug() << this << state());
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
showMessage(tr("Stopped."), StatusBar);
debugger: remove InferiorStopSpontaneous state again
2011-01-14 19:04:16 +01:00
setState(InferiorStopOk);
Debugger: Reduce line noise Move some function out of the DebuggerCore "namespace", to avoid one indirection and removes clutter in the calling code. Change-Id: I1c870d5c7eeade32fa63dedf581490fbb090cd6a Reviewed-by: Christian Stenger <christian.stenger@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2014-07-28 14:23:52 +02:00
if (boolSetting(RaiseOnInterrupt))
Debugger: Replace Internal::mainWindow ... by DebuggerMainWindow::instance() and clean up a few uses. Change-Id: I7ae4073aa97fc2f00108533bed91db330b07880f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-22 14:40:49 +02:00
ICore::raiseWindow(DebuggerMainWindow::instance());
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
EngineManager::activateEngine(this);
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
void DebuggerEngine::notifyInferiorStopFailed()
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +02:00
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR STOP FAILED");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == InferiorStopRequested, qDebug() << this << state());
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
setState(InferiorStopFailed);
Debugger: Move master engine checks around From several places in DebuggerEngine::* to one place in DebuggerEnginePrivate. Change-Id: Ic87110a11087e338cc9a6b66ea30ea2259861d9e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-12-14 10:31:44 +01:00
d->doShutdownEngine();
debugger: rename EngineStart to EngineSetup
2010-07-09 08:48:33 +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 DebuggerEnginePrivate::setInitialActionStates()
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
m_returnWindow->setVisible(false);
setBusyCursor(false);
m_recordForReverseOperationAction.setCheckable(true);
m_recordForReverseOperationAction.setChecked(false);
m_recordForReverseOperationAction.setIcon(Icons::RECORD_OFF.icon());
m_recordForReverseOperationAction.setToolTip(tr(
"<html><head/><body><p>Record information to enable stepping backwards.</p><p>"
"<b>Note:</b> This feature is very slow and unstable on the GDB side. "
"It exhibits unpredictable behavior when going backwards over system "
"calls and is very likely to destroy your debugging session.</p></body></html>"));
m_operateInReverseDirectionAction.setCheckable(true);
m_operateInReverseDirectionAction.setChecked(false);
m_operateInReverseDirectionAction.setIcon(Icons::DIRECTION_FORWARD.icon());
m_snapshotAction.setIcon(Utils::Icons::SNAPSHOT_TOOLBAR.icon());
m_attachToQmlPortAction.setEnabled(true);
m_attachToCoreAction.setEnabled(true);
m_attachToRemoteServerAction.setEnabled(true);
m_detachAction.setEnabled(false);
m_watchAction.setEnabled(true);
m_breakAction.setEnabled(false);
m_snapshotAction.setEnabled(false);
m_operateByInstructionAction.setEnabled(false);
m_exitAction.setEnabled(false);
m_abortAction.setEnabled(false);
m_resetAction.setEnabled(false);
m_interruptAction.setEnabled(false);
m_continueAction.setEnabled(false);
m_stepIntoAction.setEnabled(true);
m_stepOutAction.setEnabled(false);
m_runToLineAction.setEnabled(false);
m_runToSelectedFunctionAction.setEnabled(true);
m_returnFromFunctionAction.setEnabled(false);
m_jumpToLineAction.setEnabled(false);
m_stepOverAction.setEnabled(true);
action(AutoDerefPointers)->setEnabled(true);
action(ExpandStack)->setEnabled(false);
m_threadLabel->setEnabled(false);
}
void DebuggerEnginePrivate::updateState(bool alsoUpdateCompanion)
{
if (!m_perspective)
return;
const DebuggerState state = m_state;
const bool companionPreventsAction = m_engine->companionPreventsActions();
// Fixme: hint tr("Debugger is Busy");
// Exactly one of m_interuptAction and m_continueAction should be
// visible, possibly disabled.
if (state == DebuggerNotReady) {
// Happens when companion starts, otherwise this should not happen.
QTC_CHECK(m_companionEngine);
m_interruptAction.setVisible(true);
m_interruptAction.setEnabled(false);
m_continueAction.setVisible(false);
m_continueAction.setEnabled(false);
m_stepOverAction.setEnabled(true);
m_stepIntoAction.setEnabled(true);
m_stepOutAction.setEnabled(false);
m_exitAction.setEnabled(false);
m_debugWithoutDeployAction.setEnabled(true);
} else if (state == InferiorStopOk) {
// F5 continues, Shift-F5 kills. It is "continuable".
m_interruptAction.setVisible(false);
m_interruptAction.setEnabled(false);
m_continueAction.setVisible(true);
m_continueAction.setEnabled(!companionPreventsAction);
m_stepOverAction.setEnabled(!companionPreventsAction);
m_stepIntoAction.setEnabled(!companionPreventsAction);
m_stepOutAction.setEnabled(!companionPreventsAction);
m_exitAction.setEnabled(true);
m_debugWithoutDeployAction.setEnabled(false);
m_localsAndInspectorWindow->setShowLocals(true);
} else if (state == InferiorRunOk) {
// Shift-F5 interrupts. It is also "interruptible".
m_interruptAction.setVisible(true);
m_interruptAction.setEnabled(!companionPreventsAction);
m_continueAction.setVisible(false);
m_continueAction.setEnabled(false);
m_stepOverAction.setEnabled(false);
m_stepIntoAction.setEnabled(false);
m_stepOutAction.setEnabled(false);
m_exitAction.setEnabled(true);
m_debugWithoutDeployAction.setEnabled(false);
m_localsAndInspectorWindow->setShowLocals(false);
} else if (state == DebuggerFinished) {
const bool canRun = ProjectExplorerPlugin::canRunStartupProject(ProjectExplorer::Constants::DEBUG_RUN_MODE);
// We don't want to do anything anymore.
m_interruptAction.setVisible(true);
m_interruptAction.setEnabled(false);
m_continueAction.setVisible(false);
m_continueAction.setEnabled(false);
m_stepOverAction.setEnabled(false);
m_stepIntoAction.setEnabled(false);
m_stepOutAction.setEnabled(false);
m_exitAction.setEnabled(false);
m_debugWithoutDeployAction.setEnabled(canRun);
setBusyCursor(false);
cleanupViews();
} else if (state == InferiorUnrunnable) {
// We don't want to do anything anymore.
m_interruptAction.setVisible(true);
m_interruptAction.setEnabled(false);
m_continueAction.setVisible(false);
m_continueAction.setEnabled(false);
m_stepOverAction.setEnabled(false);
m_stepIntoAction.setEnabled(false);
m_stepOutAction.setEnabled(false);
m_exitAction.setEnabled(true);
m_debugWithoutDeployAction.setEnabled(false);
// show locals in core dumps
m_localsAndInspectorWindow->setShowLocals(true);
} else {
// Everything else is "undisturbable".
m_interruptAction.setVisible(true);
m_interruptAction.setEnabled(false);
m_continueAction.setVisible(false);
m_continueAction.setEnabled(false);
m_stepOverAction.setEnabled(false);
m_stepIntoAction.setEnabled(false);
m_stepOutAction.setEnabled(false);
m_exitAction.setEnabled(false);
m_debugWithoutDeployAction.setEnabled(false);
}
m_attachToQmlPortAction.setEnabled(true);
m_attachToCoreAction.setEnabled(true);
m_attachToRemoteServerAction.setEnabled(true);
Debugger: Simplify thread switching more This moves the thread switcher combobox, the only consumer of part of the threadhandler interface, into the threadhandler. Change-Id: Icafd72e7777fad9196ce8fb33a79cae26c29a521 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-31 18:30:14 +02:00
const bool threadsEnabled = state == InferiorStopOk || state == InferiorUnrunnable;
m_threadsHandler.threadSwitcher()->setEnabled(threadsEnabled);
m_threadLabel->setEnabled(threadsEnabled);
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 bool isCore = m_engine->runParameters().startMode == AttachCore;
const bool stopped = state == InferiorStopOk;
const bool detachable = stopped && !isCore;
m_detachAction.setEnabled(detachable);
if (stopped)
Debugger: Replace Internal::mainWindow ... by DebuggerMainWindow::instance() and clean up a few uses. Change-Id: I7ae4073aa97fc2f00108533bed91db330b07880f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-08-22 14:40:49 +02:00
QApplication::alert(ICore::mainWindow(), 3000);
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
updateReverseActions();
const bool canSnapshot = m_engine->hasCapability(SnapshotCapability);
m_snapshotAction.setVisible(canSnapshot);
m_snapshotAction.setEnabled(stopped && !isCore);
m_watchAction.setEnabled(true);
m_breakAction.setEnabled(true);
const bool canOperateByInstruction = m_engine->hasCapability(OperateByInstructionCapability);
m_operateByInstructionAction.setVisible(canOperateByInstruction);
m_operateByInstructionAction.setEnabled(canOperateByInstruction && (stopped || isCore));
m_abortAction.setEnabled(state != DebuggerNotReady
&& state != DebuggerFinished);
m_resetAction.setEnabled((stopped || state == DebuggerNotReady)
&& m_engine->hasCapability(ResetInferiorCapability));
m_stepIntoAction.setEnabled(stopped || state == DebuggerNotReady);
m_stepIntoAction.setToolTip(QString());
m_stepOverAction.setEnabled(stopped || state == DebuggerNotReady);
m_stepOverAction.setToolTip(QString());
m_stepOutAction.setEnabled(stopped);
m_runToLineAction.setEnabled(stopped && m_engine->hasCapability(RunToLineCapability));
m_runToSelectedFunctionAction.setEnabled(stopped);
m_returnFromFunctionAction.
setEnabled(stopped && m_engine->hasCapability(ReturnFromFunctionCapability));
const bool canJump = stopped && m_engine->hasCapability(JumpToLineCapability);
m_jumpToLineAction.setEnabled(canJump);
const bool actionsEnabled = m_engine->debuggerActionsEnabled();
const bool canDeref = actionsEnabled && m_engine->hasCapability(AutoDerefPointersCapability);
action(AutoDerefPointers)->setEnabled(canDeref);
action(AutoDerefPointers)->setEnabled(true);
action(ExpandStack)->setEnabled(actionsEnabled);
const bool notbusy = state == InferiorStopOk
|| state == DebuggerNotReady
|| state == DebuggerFinished
|| state == InferiorUnrunnable;
setBusyCursor(!notbusy);
if (alsoUpdateCompanion && m_companionEngine)
m_companionEngine->updateState(false);
}
void DebuggerEnginePrivate::updateReverseActions()
{
const bool stopped = m_state == InferiorStopOk;
const bool reverseEnabled = boolSetting(EnableReverseDebugging);
const bool canReverse = reverseEnabled && m_engine->hasCapability(ReverseSteppingCapability);
const bool doesRecord = m_recordForReverseOperationAction.isChecked();
m_recordForReverseOperationAction.setVisible(canReverse);
m_recordForReverseOperationAction.setEnabled(canReverse && stopped);
m_recordForReverseOperationAction.setIcon(doesRecord
? Icons::RECORD_ON.icon()
: Icons::RECORD_OFF.icon());
m_operateInReverseDirectionAction.setVisible(canReverse);
m_operateInReverseDirectionAction.setEnabled(canReverse && stopped && doesRecord);
m_operateInReverseDirectionAction.setIcon(Icons::DIRECTION_BACKWARD.icon());
m_operateInReverseDirectionAction.setText(DebuggerEngine::tr("Operate in reverse direction"));
}
void DebuggerEnginePrivate::cleanupViews()
{
const bool closeSource = boolSetting(CloseSourceBuffersOnExit);
const bool closeMemory = boolSetting(CloseMemoryBuffersOnExit);
QList<IDocument *> toClose;
foreach (IDocument *document, DocumentModel::openedDocuments()) {
const bool isMemory = document->property(Constants::OPENED_WITH_DISASSEMBLY).toBool();
if (document->property(Constants::OPENED_BY_DEBUGGER).toBool()) {
bool keepIt = true;
if (document->isModified())
keepIt = true;
else if (document->filePath().toString().contains("qeventdispatcher"))
keepIt = false;
else if (isMemory)
keepIt = !closeMemory;
else
keepIt = !closeSource;
if (keepIt)
document->setProperty(Constants::OPENED_BY_DEBUGGER, false);
else
toClose.append(document);
}
}
EditorManager::closeDocuments(toClose);
}
void DebuggerEnginePrivate::setBusyCursor(bool busy)
{
//STATE_DEBUG("BUSY FROM: " << m_busy << " TO: " << busy);
if (m_isDying)
return;
if (busy == m_busy)
return;
m_busy = busy;
const QCursor cursor(busy ? Qt::BusyCursor : Qt::ArrowCursor);
m_breakWindow->setCursor(cursor);
//m_consoleWindow->setCursor(cursor);
m_localsWindow->setCursor(cursor);
m_modulesWindow->setCursor(cursor);
m_logWindow->setCursor(cursor);
m_registerWindow->setCursor(cursor);
m_returnWindow->setCursor(cursor);
m_sourceFilesWindow->setCursor(cursor);
m_stackWindow->setCursor(cursor);
m_threadsWindow->setCursor(cursor);
m_watchersWindow->setCursor(cursor);
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: 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 DebuggerEngine::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: 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
showMessage("INFERIOR FINISHED SHUT DOWN");
Fix CDB/trkgdbadapter.
2010-07-14 16:01:53 +02:00
QTC_ASSERT(state() == InferiorShutdownRequested, qDebug() << this << state());
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
setState(InferiorShutdownFinished);
Debugger: Move master engine checks around From several places in DebuggerEngine::* to one place in DebuggerEnginePrivate. Change-Id: Ic87110a11087e338cc9a6b66ea30ea2259861d9e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-12-14 10:31:44 +01:00
d->doShutdownEngine();
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
}
void DebuggerEngine::notifyInferiorIll()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR ILL");
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
// This can be issued in almost any state. The inferior could still be
// alive as some previous notifications might have been bogus.
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
startDying();
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
if (state() == InferiorRunRequested) {
// We asked for running, but did not see a response.
// Assume the inferior is dead.
// FIXME: Use timeout?
setState(InferiorRunFailed);
setState(InferiorStopOk);
}
Debugger: Simplify queue/do pairs The functionality has been needed for asynchronous processing which are in RunWorkers nowadays, where the functionality is provided by the general RunControl framework. Change-Id: Id18f693935cd6faf5b25883dfeaace0dd691f6a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-06 08:49:36 +02:00
d->doShutdownInferior();
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: 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 DebuggerEngine::notifyEngineShutdownFinished()
debugger: refactor startup logic
2010-07-08 18:10:50 +02:00
{
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
showMessage("NOTE: ENGINE SHUTDOWN FINISHED");
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
QTC_ASSERT(state() == EngineShutdownRequested, qDebug() << this << state());
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
setState(EngineShutdownFinished);
Debugger: Simplify queue/do pairs The functionality has been needed for asynchronous processing which are in RunWorkers nowadays, where the functionality is provided by the general RunControl framework. Change-Id: Id18f693935cd6faf5b25883dfeaace0dd691f6a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-06 08:49:36 +02:00
d->doFinishDebugger();
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
}
void DebuggerEngine::notifyEngineIll()
{
Debugger: Fix crash on ramp down Change-Id: I76aab19d92eae10823196a4c6dc9a2c400d47e80 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-06-16 17:22:51 +02:00
//#ifdef WITH_BENCHMARK
// CALLGRIND_STOP_INSTRUMENTATION;
// CALLGRIND_DUMP_STATS;
//#endif
Debugger: Re-enable some shutdown cleanup code It is still needed with LLDB. Task-number: QTCREATORBUG-18723 Change-Id: If78dcbf8e074add969c403c37193c9f4ce857625 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2017-08-11 19:06:10 +02:00
showMessage("NOTE: ENGINE ILL ******");
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
startDying();
Debugger: Re-enable some shutdown cleanup code It is still needed with LLDB. Task-number: QTCREATORBUG-18723 Change-Id: If78dcbf8e074add969c403c37193c9f4ce857625 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2017-08-11 19:06:10 +02:00
switch (state()) {
case InferiorRunRequested:
case InferiorRunOk:
// The engine does not look overly ill right now, so attempt to
// properly interrupt at least once. If that fails, we are on the
// shutdown path due to d->m_targetState anyways.
setState(InferiorStopRequested, true);
showMessage("ATTEMPT TO INTERRUPT INFERIOR");
interruptInferior();
break;
case InferiorStopRequested:
notifyInferiorStopFailed();
break;
case InferiorStopOk:
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
showMessage("FORWARDING STATE TO InferiorShutdownFinished");
setState(InferiorShutdownFinished, true);
Debugger: Move master engine checks around From several places in DebuggerEngine::* to one place in DebuggerEnginePrivate. Change-Id: Ic87110a11087e338cc9a6b66ea30ea2259861d9e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-12-14 10:31:44 +01:00
d->doShutdownEngine();
Debugger: Re-enable some shutdown cleanup code It is still needed with LLDB. Task-number: QTCREATORBUG-18723 Change-Id: If78dcbf8e074add969c403c37193c9f4ce857625 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2017-08-11 19:06:10 +02:00
break;
default:
Debugger: Move master engine checks around From several places in DebuggerEngine::* to one place in DebuggerEnginePrivate. Change-Id: Ic87110a11087e338cc9a6b66ea30ea2259861d9e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-12-14 10:31:44 +01:00
d->doShutdownEngine();
Debugger: Re-enable some shutdown cleanup code It is still needed with LLDB. Task-number: QTCREATORBUG-18723 Change-Id: If78dcbf8e074add969c403c37193c9f4ce857625 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2017-08-11 19:06:10 +02:00
break;
}
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
}
void DebuggerEngine::notifyEngineSpontaneousShutdown()
{
debugger: make debuggerengine easier accessible to profiling Change-Id: I5c9ed1e994e490a6a6859afc6ae1756b09b87af9 Reviewed-by: hjk <qthjk@ovi.com>
2012-05-08 16:50:03 +02:00
#ifdef WITH_BENCHMARK
CALLGRIND_STOP_INSTRUMENTATION;
CALLGRIND_DUMP_STATS;
#endif
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: ENGINE SPONTANEOUS SHUTDOWN");
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
setState(EngineShutdownFinished, 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
d->doFinishDebugger();
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
}
void DebuggerEngine::notifyInferiorExited()
{
debugger: make debuggerengine easier accessible to profiling Change-Id: I5c9ed1e994e490a6a6859afc6ae1756b09b87af9 Reviewed-by: hjk <qthjk@ovi.com>
2012-05-08 16:50:03 +02:00
#ifdef WITH_BENCHMARK
CALLGRIND_STOP_INSTRUMENTATION;
CALLGRIND_DUMP_STATS;
#endif
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage("NOTE: INFERIOR EXITED");
debugger: remove a bit of stackview flicker by using the 80 ms timer
2010-12-17 11:30:32 +01:00
d->resetLocation();
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
setState(InferiorShutdownFinished);
Debugger: Move master engine checks around From several places in DebuggerEngine::* to one place in DebuggerEnginePrivate. Change-Id: Ic87110a11087e338cc9a6b66ea30ea2259861d9e Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-12-14 10:31:44 +01:00
d->doShutdownEngine();
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
}
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 DebuggerEngine::updateState(bool alsoUpdateCompanion)
{
d->updateState(alsoUpdateCompanion);
}
WatchTreeView *DebuggerEngine::inspectorView()
{
return d->m_inspectorView;
}
void DebuggerEngine::showMessage(const QString &msg, int channel, int timeout) const
{
//qDebug() << "PLUGIN OUTPUT: " << channel << msg;
QTC_ASSERT(d->m_logWindow, qDebug() << "MSG: " << msg; return);
switch (channel) {
case StatusBar:
d->m_logWindow->showInput(LogMisc, msg);
d->m_logWindow->showOutput(LogMisc, msg);
Debugger::showStatusMessage(msg, timeout);
break;
case LogMiscInput:
d->m_logWindow->showInput(LogMisc, msg);
d->m_logWindow->showOutput(LogMisc, msg);
break;
case LogInput:
d->m_logWindow->showInput(LogInput, msg);
d->m_logWindow->showOutput(LogInput, msg);
break;
case LogError:
d->m_logWindow->showInput(LogError, QLatin1String("ERROR: ") + msg);
d->m_logWindow->showOutput(LogError, QLatin1String("ERROR: ") + msg);
break;
case AppOutput:
case AppStuff:
d->m_logWindow->showOutput(channel, msg);
emit appendMessageRequested(msg, StdOutFormatSameLine, false);
break;
case AppError:
d->m_logWindow->showOutput(channel, msg);
emit appendMessageRequested(msg, StdErrFormatSameLine, false);
break;
default:
d->m_logWindow->showOutput(channel, msg);
break;
}
}
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 DebuggerEngine::notifyDebuggerProcessFinished(int exitCode,
QProcess::ExitStatus exitStatus, const QString &backendName)
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage(QString("%1 PROCESS FINISHED, status %2, exit code %3")
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
.arg(backendName).arg(exitStatus).arg(exitCode));
switch (state()) {
case DebuggerFinished:
// Nothing to do.
break;
case EngineShutdownRequested:
Debugger: Prevent popup on shutdown when debugger is running * Run a debugger (of any kind) * Close Qt Creator window * When prompted to shutdown choose Yes * An error message box appears with "Unexpected GDB exit" This is not a real solution, but a quick hack to make the error message go. 2 soft assertions are also hit on this case: SOFT ASSERT: "state() == EngineShutdownRequested" in file debuggerengine.cpp, line 1130 Debugger::Internal::GdbTermEngine(0x55ef651cea30, name = "GdbEngine") "InferiorShutdownRequested" *** UNEXPECTED STATE TRANSITION: Debugger::Internal::GdbTermEngine(0x55ef651cea30, name = "GdbEngine") "State changed from InferiorShutdownRequested(16) to EngineShutdownOk(21) [master]" SOFT ASSERT: "state() == InferiorShutdownRequested" in file debuggerengine.cpp, line 1068 Debugger::Internal::GdbTermEngine(0x55ef651cea30, name = "GdbEngine") "DebuggerFinished" UNEXPECTED STATE: 22 WANTED: 16 IN gdbengine.cpp:1841 They are *not* addressed in this patch. Task-number: QTCREATORBUG-16770 Change-Id: I419f134e527a154dfbe1c85a3fd6629597a363f0 Reviewed-by: hjk <hjk@qt.io>
2016-11-12 23:20:32 +02:00
case InferiorShutdownRequested:
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
notifyEngineShutdownFinished();
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
break;
case InferiorRunOk:
// This could either be a real gdb/lldb crash or a quickly exited inferior
// in the terminal adapter. In this case the stub proc will die soon,
// too, so there's no need to act here.
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage(QString("The %1 process exited somewhat unexpectedly.").arg(backendName));
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
notifyEngineSpontaneousShutdown();
break;
default: {
Debugger: Fix creator crash on spontanous debugger exit. Task-number: QTCREATORBUG-16233 Change-Id: I27b9ab17243463924dc410b3b5ffb0795ef3e33c Reviewed-by: hjk <hjk@theqtcompany.com>
2016-05-18 15:52:24 +02:00
// Initiate shutdown sequence
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
notifyInferiorIll();
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
const QString msg = exitStatus == QProcess::CrashExit ?
tr("The %1 process terminated.") :
Debugger: fix UI text capitalization and punctuation Added full stops to ends of messages. Used book-style capitalization for message box titles. Wrote "operating system" in lower case. Change-Id: I8cee1a1c7f4ae55952daa507395845feae203ab9 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-03-16 15:34:45 +01:00
tr("The %2 process terminated unexpectedly (exit code %1).").arg(exitCode);
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
AsynchronousMessageBox::critical(tr("Unexpected %1 Exit").arg(backendName),
msg.arg(backendName));
break;
}
}
}
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
static QString msgStateChanged(DebuggerState oldState, DebuggerState newState, bool forced)
Debugger: Compile with QT_NO_CAST_FROM_ASCII. (except gdbmi.cpp, name_demangler.cpp). Remove some unneeded conversions, change some maps to take QByteArray keys. Change-Id: I010f1251998a441fe5c8c87901b1e0c277c0391c Reviewed-by: hjk <qthjk@ovi.com>
2011-12-21 14:02:52 +01:00
{
QString result;
QTextStream str(&result);
str << "State changed";
if (forced)
str << " BY FORCE";
str << " from " << DebuggerEngine::stateName(oldState) << '(' << oldState
<< ") to " << DebuggerEngine::stateName(newState) << '(' << newState << ')';
return result;
}
debugger: The DebuggerEngine refactoring. This replaces the (de facto) singleton engines and data handlers by classes that are instantiated per run. The DebuggerRunControl will now create an object of (a class derived from) DebuggerEngine that contains all the relevant "dynamic" data. DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin, whereas the data bits went to DebuggerEngine. There is no formal notion of a "current" DebuggerEngine. However, as there's only one DebuggerEngine at a time that has its data models connected to the view, there's still some "de facto" notion of a "current" engine. Calling SomeModel::setData(int role, QVariant data) with custom role is used as the primary dispatch mechanism from the views to the "current" data models (and the engine, as all data models know their engine).
2010-06-16 11:08:54 +02:00
void DebuggerEngine::setState(DebuggerState state, bool forced)
{
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 QString msg = msgStateChanged(d->m_state, state, forced);
Debugger: Bring back debug output.
2010-11-15 17:36:00 +01:00
debugger: remove special mechanism to update watcher and return window
2010-06-23 14:11:52 +02:00
DebuggerState oldState = d->m_state;
d->m_state = state;
if (!forced && !isAllowedTransition(oldState, state))
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
qDebug() << "*** UNEXPECTED STATE TRANSITION: " << this << msg;
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: 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
if (state == EngineRunRequested)
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
emit engineStarted();
debugger: Refactor breakpoint handling. The breakpoints are now (fairly) tightly guarded by the BreakpointHandler. Engines and Views are only supposed to refer to them by id. They also have individual states now. The breakpoint data is split into a "user requested" "fixed" part in BreakpointData and the engines' acknowledged data in a new struct BreakpointResponse. TODO: Move m_state and m_engine members to BreakpointResponse. Fix regressions in the marker handling.
2010-11-10 16:33:11 +01:00
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
showMessage(msg, LogDebug);
debugger: prepare removal of plugin()->updateState(this);
2010-10-27 14:21:33 +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
d->updateState(true);
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
if (oldState != d->m_state)
emit EngineManager::instance()->engineStateChanged(this);
debugger: re-do state transitions in combined C++/Qml engine This still needs a lot of work and sanitizing.
2011-01-14 14:25:02 +01:00
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
if (state == DebuggerFinished) {
d->destroyPerspective();
emit engineFinished();
}
debugger: simplify DebuggerEngine construction The master engine pointer can be given later. Change-Id: I4d72679dcbd5fe7291067a5e78c984d26cc187aa Reviewed-by: hjk <qthjk@ovi.com>
2012-08-15 14:33:39 +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 DebuggerEngine::isPrimaryEngine() const
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
return d->m_isPrimaryEngine;
debugger: reorganize debuggerengine.h
2011-01-12 13:43:23 +01: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
bool DebuggerEngine::canDisplayTooltip() const
{
return state() == InferiorStopOk;
}
ScriptConsole: Show File and Line Info Show File and Line Info for items that have the info. Clicking on the item opens the file and sets the cursor position on the line. The context menu also provides option to copy contents and option to clear the view. Change-Id: I161de392ba35e37d323b049371619b01c617c798 Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
2012-02-22 11:50:05 +01:00
QString DebuggerEngine::toFileInProject(const QUrl &fileUrl)
{
// make sure file finder is properly initialized
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
const DebuggerRunParameters &rp = runParameters();
d->m_fileFinder.setProjectDirectory(rp.projectSourceDirectory);
d->m_fileFinder.setProjectFiles(rp.projectSourceFiles);
d->m_fileFinder.setAdditionalSearchDirectories(rp.additionalSearchDirectories);
d->m_fileFinder.setSysroot(rp.sysRoot);
ScriptConsole: Show File and Line Info Show File and Line Info for items that have the info. Clicking on the item opens the file and sets the cursor position on the line. The context menu also provides option to copy contents and option to clear the view. Change-Id: I161de392ba35e37d323b049371619b01c617c798 Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
2012-02-22 11:50:05 +01:00
return d->m_fileFinder.findFile(fileUrl);
}
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 DebuggerEngine::expand(const QString &string) const
{
Debugger: Move run parameters from engine to tool runner The parameters belong to the run control, they should not be triplicated in case of a combined engine. Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-05 14:45:36 +02:00
return runParameters().macroExpander->expand(string);
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: 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 DebuggerEngine::nativeStartupCommands() const
{
return expand(QStringList({stringSetting(GdbStartupCommands),
runParameters().additionalStartupCommands}).join('\n'));
}
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
Perspective *DebuggerEngine::perspective() const
Debugger: Fix removal of breakpoint marks in disassembler view Task-number: QTCREATORBUG-14973 Change-Id: I6dfceefe6d8b1404c2a553dbeebd7dccefa1a624 Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-08-31 16:35:24 +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
return d->m_perspective;
}
void DebuggerEngine::updateMarkers()
{
if (d->m_locationMark)
d->m_locationMark->updateIcon();
d->m_disassemblerAgent.updateLocationMarker();
Debugger: Remove breakpoint mark from assembler view ... after deletion. The breakpoint itself was actually removed from the breakpoint view but the red blob stayed until the next update (e.g. after the next 'step') Change-Id: I120059a6e643df7c104a8f6d96e09b9c707d14d8 Reviewed-by: Niels Weber <niels.weber@theqtcompany.com>
2015-07-21 15:28:31 +02:00
}
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 DebuggerEngine::updateToolTips()
{
d->m_toolTipManager.updateToolTips();
}
DebuggerToolTipManager *DebuggerEngine::toolTipManager()
{
return &d->m_toolTipManager;
}
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 DebuggerEngine::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
return debuggerActionsEnabledHelper(d->m_state);
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
bool DebuggerEngine::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
{
return false;
}
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 DebuggerEngine::notifyInferiorPid(const 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
{
Debugger: Use ProcessHandle in notifyInferiorPid() Change-Id: Idcb6819b64964b6aa0e72d182cc628feba37ba55 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-03-01 09:35:28 +01:00
if (d->m_inferiorPid == 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
return;
Debugger: Use ProcessHandle in notifyInferiorPid() Change-Id: Idcb6819b64964b6aa0e72d182cc628feba37ba55 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-03-01 09:35:28 +01:00
d->m_inferiorPid = pid;
if (pid.isValid()) {
showMessage(tr("Taking notice of pid %1").arg(pid.pid()));
Debugger: Move run parameters from engine to tool runner The parameters belong to the run control, they should not be triplicated in case of a combined engine. Change-Id: I4dd84220edbd7a44b902cc52627fe01d0568db75 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-05 14:45:36 +02:00
DebuggerStartMode sm = runParameters().startMode;
if (sm == StartInternal || sm == StartExternal || sm == AttachExternal)
ProjectExplorer: Remove RunControl::bringApplicationToForeground ... and replace it by direct uses of ProcessHandle::activate(). Change-Id: I7beffba7bfbeff72a81b8699ff54a311a74ce1a3 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-07-13 17:39:42 +02:00
d->m_inferiorPid.activate();
Debugger: Use base class PID mechanism in CDB. Fix base engine to raise app only in applicable modes.
2011-04-28 10:02:34 +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
}
qint64 DebuggerEngine::inferiorPid() const
{
Debugger: Use Utils::ProcessHandle for DebuggerEngine::m_inferiorPid That's the intended "typesafe" use. Change-Id: Ib288fe87a47bd9484bda83e05406f0d22989b3c2 Reviewed-by: David Schulz <david.schulz@qt.io>
2017-02-27 13:30:08 +01:00
return d->m_inferiorPid.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
}
bool DebuggerEngine::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
return d->m_operateInReverseDirectionAction.isChecked();
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 DebuggerEngine::handleBeginOfRecordingReached()
{
showStatusMessage(tr("Reverse-execution history exhausted. Going forward again."));
d->m_operateInReverseDirectionAction.setChecked(false);
d->updateReverseActions();
}
void DebuggerEngine::handleRecordingFailed()
Debugger: Make DebuggerRunTool (more) responsible for output Make DebuggerRunTool accessible to downstream users, but remove the non-standard handleApplicationOutput from the run control itself to move it closer to the base run control. LogChannel and Utils::OutputFormat should merge at some time. Change-Id: I47b0f0067e1427b25e47036c3d4bc6ed5eed6189 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-04-10 13:57:05 +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
showStatusMessage(tr("Reverse-execution recording failed.."));
d->m_operateInReverseDirectionAction.setChecked(false);
d->m_recordForReverseOperationAction.setChecked(false);
d->updateReverseActions();
executeRecordReverse(false);
Debugger: Make DebuggerRunTool (more) responsible for output Make DebuggerRunTool accessible to downstream users, but remove the non-standard handleApplicationOutput from the run control itself to move it closer to the base run control. LogChannel and Utils::OutputFormat should merge at some time. Change-Id: I47b0f0067e1427b25e47036c3d4bc6ed5eed6189 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-04-10 13:57:05 +02:00
}
debugger: code cosmetics
2010-11-18 17:32:41 +01:00
// Called by DebuggerRunControl.
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
void DebuggerEngine::quitDebugger()
{
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
showMessage(QString("QUIT DEBUGGER REQUESTED IN STATE %1").arg(state()));
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
startDying();
Debugger: Improve exit handling.
2010-08-18 11:08:50 +02:00
switch (state()) {
case InferiorStopOk:
case InferiorStopFailed:
Debugger: Add missing state cases in quitDebugger * Aborting a core dump debugging is a valid state * Do not try to abort more than once (happens on shutdown) Change-Id: I075409b3fa1231420fcd72706b18eaa0383fd4f2 Reviewed-by: hjk <hjk@qt.io>
2017-07-06 16:24:15 +03:00
case InferiorUnrunnable:
Debugger: Simplify queue/do pairs The functionality has been needed for asynchronous processing which are in RunWorkers nowadays, where the functionality is provided by the general RunControl framework. Change-Id: Id18f693935cd6faf5b25883dfeaace0dd691f6a7 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-10-06 08:49:36 +02:00
d->doShutdownInferior();
Debugger: Improve exit handling.
2010-08-18 11:08:50 +02:00
break;
case InferiorRunOk:
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
setState(InferiorStopRequested);
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
showMessage(tr("Attempting to interrupt."), StatusBar);
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
interruptInferior();
Debugger: Improve exit handling.
2010-08-18 11:08:50 +02:00
break;
DebuggerEngine: Avoid warning when aborting in EngineSetupRequested state This can happen e.g. inside the QmlEngine as part of a QmlCppEngine. Change-Id: Id649086b3febe91e73d4784f3abb7f6d7a0d0d50 Reviewed-by: hjk <qthjk@ovi.com>
2012-01-19 10:49:50 +01:00
case EngineSetupRequested:
notifyEngineSetupFailed();
break;
QmlCppDebugger: Fix transitions if cpp engine fails in setup step The CppEngine can abort the setup (e.g. because no valid debugger is found) in state EngineSetupRequested. In this case the Qml Engine will be already in state EngineSetupOk ... let it gracefully move to InferiorSetupFailed via InferiorSetupRequested. Change-Id: Ib2fe81193db30b7fa2db15e898d294182f8fc76d Reviewed-by: hjk <qthjk@ovi.com>
2012-02-21 15:59:38 +01:00
case EngineSetupOk:
Debugger: Merge EngineSetup and InferiorSetup start phases It was needed in the past to trigger e.g. gdbserver setup in remote cases which is nowadays handled by separate RunWorkers. Change-Id: I30bce071dab0779cce2e7abef7b31550d8539461 Reviewed-by: Christian Stenger <christian.stenger@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-11-15 17:12:03 +01:00
notifyEngineSetupFailed();
QmlCppDebugger: Fix transitions if cpp engine fails in setup step The CppEngine can abort the setup (e.g. because no valid debugger is found) in state EngineSetupRequested. In this case the Qml Engine will be already in state EngineSetupOk ... let it gracefully move to InferiorSetupFailed via InferiorSetupRequested. Change-Id: Ib2fe81193db30b7fa2db15e898d294182f8fc76d Reviewed-by: hjk <qthjk@ovi.com>
2012-02-21 15:59:38 +01:00
break;
QmlCppDebugger: Decouple states of engines The main engine now follows mostly the state of the gdb engine, only if a breakpoint is hit/while stepping the state of the qml engine is used. This allows us to hit C++ breakpoints at any time (also when the qml engine hasn't been able to connect yet), and also fixes the invalid transition warnings. Change-Id: If67a56fd28b098952be2606d0a46e04c27835f66 Reviewed-on: http://codereview.qt-project.org/5897 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-09-29 16:49:18 +02:00
case EngineRunRequested:
notifyEngineRunFailed();
break;
DebuggerEngine: Avoid warning when aborting in EngineShutdownRequested state Change-Id: Ib0e0a2bbf0fa7d109a3910d0814ec9edef130dc4 Reviewed-by: hjk <qthjk@ovi.com>
2012-01-19 11:46:22 +01:00
case EngineShutdownRequested:
Debugger: Add missing state cases in quitDebugger * Aborting a core dump debugging is a valid state * Do not try to abort more than once (happens on shutdown) Change-Id: I075409b3fa1231420fcd72706b18eaa0383fd4f2 Reviewed-by: hjk <hjk@qt.io>
2017-07-06 16:24:15 +03:00
case InferiorShutdownRequested:
DebuggerEngine: Avoid warning when aborting in EngineShutdownRequested state Change-Id: Ib0e0a2bbf0fa7d109a3910d0814ec9edef130dc4 Reviewed-by: hjk <qthjk@ovi.com>
2012-01-19 11:46:22 +01:00
break;
QmlCppDebugger: Decouple states of engines The main engine now follows mostly the state of the gdb engine, only if a breakpoint is hit/while stepping the state of the qml engine is used. This allows us to hit C++ breakpoints at any time (also when the qml engine hasn't been able to connect yet), and also fixes the invalid transition warnings. Change-Id: If67a56fd28b098952be2606d0a46e04c27835f66 Reviewed-on: http://codereview.qt-project.org/5897 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-09-29 16:49:18 +02:00
case EngineRunFailed:
case DebuggerFinished:
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
case InferiorShutdownFinished:
QmlCppDebugger: Decouple states of engines The main engine now follows mostly the state of the gdb engine, only if a breakpoint is hit/while stepping the state of the qml engine is used. This allows us to hit C++ breakpoints at any time (also when the qml engine hasn't been able to connect yet), and also fixes the invalid transition warnings. Change-Id: If67a56fd28b098952be2606d0a46e04c27835f66 Reviewed-on: http://codereview.qt-project.org/5897 Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
2011-09-29 16:49:18 +02:00
break;
Debugger: Improve exit handling.
2010-08-18 11:08:50 +02:00
default:
debugger: code cosmetics
2010-11-18 17:32:41 +01:00
// FIXME: We should disable the actions connected to that.
debugger: somewhat more graceful shutdown in known situations
2010-07-20 15:12:29 +02:00
notifyInferiorIll();
Debugger: Improve exit handling.
2010-08-18 11:08:50 +02:00
break;
debugger: somewhat more graceful shutdown in known situations
2010-07-20 15:12:29 +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
}
debugger: re-enable setting breakpoints while inferior is running
2010-07-20 12:14:59 +02:00
void DebuggerEngine::requestInterruptInferior()
{
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
QTC_ASSERT(state() == InferiorRunOk, qDebug() << this << state());
setState(InferiorStopRequested);
showMessage("CALL: INTERRUPT INFERIOR");
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
showMessage(tr("Attempting to interrupt."), StatusBar);
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
interruptInferior();
debugger: re-enable setting breakpoints while inferior is running
2010-07-20 12:14:59 +02:00
}
debugger: move progress handling to debugger engine base class
2010-07-21 11:02:51 +02:00
void DebuggerEngine::progressPing()
{
debugger: improve launch progress display
2010-07-22 12:02:09 +02:00
int progress = qMin(d->m_progress.progressValue() + 2, 800);
d->m_progress.setProgressValue(progress);
debugger: move progress handling to debugger engine base class
2010-07-21 11:02:51 +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 DebuggerEngine::isStartupRunConfiguration() const
Debugger: Make DebuggerRunTool (more) responsible for output Make DebuggerRunTool accessible to downstream users, but remove the non-standard handleApplicationOutput from the run control itself to move it closer to the base run control. LogChannel and Utils::OutputFormat should merge at some time. Change-Id: I47b0f0067e1427b25e47036c3d4bc6ed5eed6189 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-04-10 13:57:05 +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
return d->m_runConfiguration == RunConfiguration::startupRunConfiguration();
}
void DebuggerEngine::setCompanionEngine(DebuggerEngine *engine)
{
d->m_companionEngine = engine;
}
void DebuggerEngine::setSecondaryEngine()
{
d->m_isPrimaryEngine = false;
Debugger: Make DebuggerRunTool (more) responsible for output Make DebuggerRunTool accessible to downstream users, but remove the non-standard handleApplicationOutput from the run control itself to move it closer to the base run control. LogChannel and Utils::OutputFormat should merge at some time. Change-Id: I47b0f0067e1427b25e47036c3d4bc6ed5eed6189 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-04-10 13:57:05 +02:00
}
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 *DebuggerEngine::terminal() const
Debugger: Introduce a pty based channel to inferiors This is experimental for now and requires QTC_USE_PTY=1 in the environment to be used. Change-Id: I460ce7b9283467d481e903f731f4243b7e5ec094 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-01-14 16:58:10 +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
return d->m_terminalRunner;
Debugger: Introduce a pty based channel to inferiors This is experimental for now and requires QTC_USE_PTY=1 in the environment to be used. Change-Id: I460ce7b9283467d481e903f731f4243b7e5ec094 Reviewed-by: Fawzi Mohamed <fawzi.mohamed@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2015-01-14 16:58:10 +01: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
void DebuggerEngine::selectWatchData(const QString &)
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: 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
void DebuggerEngine::watchPoint(const QPoint &pnt)
{
DebuggerCommand cmd("watchPoint", NeedsFullStop);
cmd.arg("x", pnt.x());
cmd.arg("y", pnt.y());
cmd.callback = [this](const DebuggerResponse &response) {
qulonglong addr = response.data["selected"].toAddress();
if (addr == 0)
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
showMessage(tr("Could not find a widget."), StatusBar);
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
// Add the watcher entry nevertheless, as that's the place where
// the user expects visual feedback.
watchHandler()->watchExpression(response.data["expr"].data(), QString(), true);
};
runCommand(cmd);
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: 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
void DebuggerEngine::runCommand(const DebuggerCommand &)
{
// Overridden in the engines that use the interface.
QTC_CHECK(false);
}
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
void DebuggerEngine::fetchDisassembler(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
{
}
void DebuggerEngine::activateFrame(int)
{
}
void DebuggerEngine::reloadModules()
{
}
void DebuggerEngine::examineModules()
{
}
void DebuggerEngine::loadSymbols(const QString &)
{
}
void DebuggerEngine::loadAllSymbols()
{
}
debugger: add an option to load "missing" symbols for current stack
2010-12-21 13:34:59 +01:00
void DebuggerEngine::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
void DebuggerEngine::requestModuleSymbols(const QString &)
{
}
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
void DebuggerEngine::requestModuleSections(const QString &)
{
}
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
void DebuggerEngine::reloadRegisters()
{
}
void DebuggerEngine::reloadSourceFiles()
{
}
void DebuggerEngine::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
void DebuggerEngine::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
void DebuggerEngine::reloadDebuggingHelpers()
{
}
Core: Static pattern for ProgressManager, clean up all users Change-Id: I4af8793ca69a3af9e99baeb7c31dad3864266f91 Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>
2013-08-30 09:22:42 +02:00
void DebuggerEngine::addOptionPages(QList<IOptionsPage*> *) 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
{
}
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 DebuggerEngine::qtNamespace() 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
{
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
return d->m_qtNamespace;
}
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
void DebuggerEngine::setQtNamespace(const QString &ns)
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
{
d->m_qtNamespace = ns;
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
}
void DebuggerEngine::createSnapshot()
{
}
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
void DebuggerEngine::updateLocals()
{
watchHandler()->resetValueCache();
doUpdateLocals(UpdateParameters());
}
Debugger: Move DebuggerEngine/QmlEngine/QmlCppEngine into Debugger{} namespace (from Debugger::Internal) as they are exported classes. Introduce private classes to avoid exposing private JS debugger headers.
2010-09-13 13:30:35 +02:00
void DebuggerEngine::updateAll()
{
}
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 DebuggerEngine::displayName() 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
{
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
//: e.g. LLDB for "myproject", shows up i
return tr("%1 for \"%2\"").arg(d->m_debuggerName, runParameters().displayName);
Debugger: Re-work breakpoint storage handling The actual data is now in a TreeModel. As interface to individual breakpoints there's a new Breakpoint class essentially providing a checked handle. On the user code side breakHandler()->foo(bpId) is replaced by bp.foo(). Change-Id: I82f435bad6301fce85a1d82bf6bf39e9ddba511e Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-01-10 01:07:01 +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
void DebuggerEngine::insertBreakpoint(const Breakpoint &bp)
Debugger: Re-work breakpoint storage handling The actual data is now in a TreeModel. As interface to individual breakpoints there's a new Breakpoint class essentially providing a checked handle. On the user code side breakHandler()->foo(bpId) is replaced by bp.foo(). Change-Id: I82f435bad6301fce85a1d82bf6bf39e9ddba511e Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-01-10 01:07:01 +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
QTC_ASSERT(bp, return);
BreakpointState state = bp->state();
QTC_ASSERT(state == BreakpointInsertionRequested,
qDebug() << bp->modelId() << this << state);
New QTC_CHECK warning replacing QTC_ASSERT(x, /**/) Warn if the condition fails, but otherwise don't change the execution flow. Change-Id: Id7b14c745109b66960add967b2a4ef8d31e1a546 Reviewed-on: http://codereview.qt.nokia.com/2389 Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
2011-07-29 12:00:11 +02:00
QTC_CHECK(false);
Asynchronous breakpoint handling
2010-11-08 18:55:32 +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
void DebuggerEngine::removeBreakpoint(const Breakpoint &bp)
Asynchronous breakpoint handling
2010-11-08 18:55:32 +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
QTC_ASSERT(bp, return);
BreakpointState state = bp->state();
Debugger: Re-work breakpoint storage handling The actual data is now in a TreeModel. As interface to individual breakpoints there's a new Breakpoint class essentially providing a checked handle. On the user code side breakHandler()->foo(bpId) is replaced by bp.foo(). Change-Id: I82f435bad6301fce85a1d82bf6bf39e9ddba511e Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
2015-01-10 01:07:01 +01:00
QTC_ASSERT(state == BreakpointRemoveRequested,
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
qDebug() << bp->responseId() << this << state);
New QTC_CHECK warning replacing QTC_ASSERT(x, /**/) Warn if the condition fails, but otherwise don't change the execution flow. Change-Id: Id7b14c745109b66960add967b2a4ef8d31e1a546 Reviewed-on: http://codereview.qt.nokia.com/2389 Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
2011-07-29 12:00:11 +02:00
QTC_CHECK(false);
Asynchronous breakpoint handling
2010-11-08 18:55:32 +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
void DebuggerEngine::updateBreakpoint(const Breakpoint &bp)
Asynchronous breakpoint handling
2010-11-08 18:55:32 +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
QTC_ASSERT(bp, return);
BreakpointState state = bp->state();
QTC_ASSERT(state == BreakpointUpdateRequested,
qDebug() << bp->responseId() << this << state);
New QTC_CHECK warning replacing QTC_ASSERT(x, /**/) Warn if the condition fails, but otherwise don't change the execution flow. Change-Id: Id7b14c745109b66960add967b2a4ef8d31e1a546 Reviewed-on: http://codereview.qt.nokia.com/2389 Reviewed-by: Eike Ziller <eike.ziller@nokia.com>
2011-07-29 12:00:11 +02:00
QTC_CHECK(false);
Asynchronous breakpoint handling
2010-11-08 18:55:32 +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
void DebuggerEngine::enableSubBreakpoint(const SubBreakpoint &sbp, bool)
Debugger: Allow disabling individual breakpoint locations ... for breakpoints that resolve to multiple locations, like templates. Toggling is done via the the breakpoint view context menu, for now only available with GDB and not persistent. Change-Id: I098ae13a5518e9f671c647680f8bd4413e7e5ccc Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-01-31 10:46:57 +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
QTC_ASSERT(sbp, return);
Debugger: Allow disabling individual breakpoint locations ... for breakpoints that resolve to multiple locations, like templates. Toggling is done via the the breakpoint view context menu, for now only available with GDB and not persistent. Change-Id: I098ae13a5518e9f671c647680f8bd4413e7e5ccc Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-01-31 10:46:57 +01:00
QTC_CHECK(false);
}
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
void DebuggerEngine::assignValueInDebugger(WatchItem *,
debugger: s/*ViewAgent/*Agent/ to reduce noise and match file names
2010-12-14 12:29:32 +01:00
const QString &, const QVariant &)
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: 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 DebuggerEngine::handleRecordReverse(bool record)
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: 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
executeRecordReverse(record);
d->updateReverseActions();
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: 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 DebuggerEngine::handleReverseDirection(bool reverse)
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: 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
executeReverse(reverse);
updateMarkers();
d->updateReverseActions();
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: 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 DebuggerEngine::executeDebuggerCommand(const QString &)
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: 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
showMessage(tr("This debugger cannot handle user input."), StatusBar);
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 DebuggerEngine::isDying() 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
return d->m_isDying;
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: 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
QString DebuggerEngine::msgStopped(const QString &reason)
{
Debugger: fix UI text capitalization and punctuation Added full stops to ends of messages. Used book-style capitalization for message box titles. Wrote "operating system" in lower case. Change-Id: I8cee1a1c7f4ae55952daa507395845feae203ab9 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-03-16 15:34:45 +01:00
return reason.isEmpty() ? tr("Stopped.") : tr("Stopped: \"%1\".").arg(reason);
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
}
debugger: code cosmetics
2010-11-18 17:32:41 +01:00
QString DebuggerEngine::msgStoppedBySignal(const QString &meaning,
const 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
{
debugger: more verbose status message on sigsegv even if messagebox was disabled
2011-02-23 11:28:20 +01:00
return tr("Stopped: %1 (Signal %2).").arg(meaning, 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
}
debugger: code cosmetics
2010-11-18 17:32:41 +01:00
QString DebuggerEngine::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
{
return tr("Stopped in thread %1 by: %2.").arg(threadId, description);
}
QString DebuggerEngine::msgInterrupted()
{
return tr("Interrupted.");
}
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 DebuggerEngine::showStoppedBySignalMessageBox(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
{
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
if (d->m_alertBox)
return false;
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
if (name.isEmpty())
Debugger: Clean up debuggerengine.cpp Some leftover stringfreeze workaround, plus QLatin1*. Change-Id: I5e143af5cda64cb29b7769174187fc86185a89cb Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2016-06-27 16:40:23 +02:00
name = ' ' + tr("<Unknown>", "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
if (meaning.isEmpty())
Debugger: Clean up debuggerengine.cpp Some leftover stringfreeze workaround, plus QLatin1*. Change-Id: I5e143af5cda64cb29b7769174187fc86185a89cb Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2016-06-27 16:40:23 +02:00
meaning = ' ' + tr("<Unknown>", "meaning") + ' ';
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
const QString msg = tr("<p>The inferior stopped because it received a "
Debugger: fix UI text capitalization and punctuation Added full stops to ends of messages. Used book-style capitalization for message box titles. Wrote "operating system" in lower case. Change-Id: I8cee1a1c7f4ae55952daa507395845feae203ab9 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-03-16 15:34:45 +01:00
"signal from the operating system.<p>"
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
"<table><tr><td>Signal name : </td><td>%1</td></tr>"
"<tr><td>Signal meaning : </td><td>%2</td></tr></table>")
.arg(name, meaning);
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
d->m_alertBox = AsynchronousMessageBox::information(tr("Signal Received"), msg);
return true;
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 DebuggerEngine::showStoppedByExceptionMessageBox(const QString &description)
{
debugger: code cosmetics
2010-11-18 17:32:41 +01:00
const QString msg =
tr("<p>The inferior stopped because it triggered an exception.<p>%1").
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
arg(description);
Debugger: Remove unneeded qualifications Mostly done using the following ruby script: Dir.glob('**/*.cpp').each { |file| next if file =~ %r{src/shared/qbs|/qmljs/} s = File.read(file) s.scan(/^using namespace (.*);$/) { ns = $1 t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m| before = $1 char = $2 if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/ m else before + char end } if t != s puts file File.open(file, 'w').write(t) end } } Change-Id: I1aa1a2b6ccbafeb1a8f3053fffa39b3f96992591 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-02-03 23:58:49 +02:00
AsynchronousMessageBox::information(tr("Exception Triggered"), msg);
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
}
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
void DebuggerEngine::openMemoryView(const MemoryViewSetupData &data)
debugger: split debuggeragents.{h,cpp} int {memory,disassembler}agent.{h,cpp}
2010-12-08 12:43:11 +01:00
{
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
d->m_memoryAgents.createBinEditor(data, this);
Debugger: Add memory views. Add a separate memory view tool window available from the context menus of: Locals view: If the debugger provides size information, colors the areas of member variables for inspecting class layouts. Registers view: Tracks the area pointed to by a register. The view has a context menu allowing to open subviews referenced by the pointer at the location using the toolchain abi's word with/endianness. Rubber-stamped-by: hjk
2011-04-08 16:18:47 +02:00
}
debugger: move MemoryViewAgent ownership to DebuggerEngine
2010-12-13 18:17:31 +01:00
void DebuggerEngine::updateMemoryViews()
{
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
d->m_memoryAgents.updateContents();
debugger: split debuggeragents.{h,cpp} int {memory,disassembler}agent.{h,cpp}
2010-12-08 12:43:11 +01:00
}
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
void DebuggerEngine::openDisassemblerView(const Location &location)
debugger: split debuggeragents.{h,cpp} int {memory,disassembler}agent.{h,cpp}
2010-12-08 12:43:11 +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
DisassemblerAgent *agent = new DisassemblerAgent(this);
debugger: introduce the concept of a 'Location', used by gotoLocation
2010-12-16 19:06:33 +01:00
agent->setLocation(location);
debugger: split debuggeragents.{h,cpp} int {memory,disassembler}agent.{h,cpp}
2010-12-08 12:43:11 +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
void DebuggerEngine::raiseWatchersWindow()
{
if (d->m_watchersView) {
if (auto dock = qobject_cast<QDockWidget *>(d->m_watchersView->parentWidget())) {
if (QAction *act = dock->toggleViewAction()) {
if (!act->isChecked())
QTimer::singleShot(1, act, [act] { act->trigger(); });
dock->raise();
}
}
}
}
void DebuggerEngine::openMemoryEditor()
{
AddressDialog dialog;
if (dialog.exec() != QDialog::Accepted)
return;
MemoryViewSetupData data;
data.startAddress = dialog.address();
openMemoryView(data);
}
void DebuggerEngine::updateLocalsView(const GdbMi &all)
{
WatchHandler *handler = watchHandler();
const GdbMi typeInfo = all["typeinfo"];
handler->recordTypeInfo(typeInfo);
const GdbMi data = all["data"];
handler->insertItems(data);
const GdbMi ns = all["qtnamespace"];
if (ns.isValid()) {
setQtNamespace(ns.data());
showMessage("FOUND NAMESPACED QT: " + ns.data());
}
static int count = 0;
showMessage(QString("<Rebuild Watchmodel %1 @ %2 >")
.arg(++count).arg(LogWindow::logTimeStamp()), LogMiscInput);
showMessage(tr("Finished retrieving data"), 400, StatusBar);
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
d->m_toolTipManager.updateToolTips();
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 bool partial = all["partial"].toInt();
if (!partial)
updateMemoryViews();
}
bool DebuggerEngine::canHandleToolTip(const DebuggerToolTipContext &context) const
{
return state() == InferiorStopOk && context.isCppEditor;
}
void DebuggerEngine::updateItem(const QString &iname)
{
if (d->m_lookupRequests.contains(iname)) {
showMessage(QString("IGNORING REPEATED REQUEST TO EXPAND " + iname));
WatchHandler *handler = watchHandler();
WatchItem *item = handler->findItem(iname);
QTC_CHECK(item);
WatchModelBase *model = handler->model();
QTC_CHECK(model);
if (item && !model->hasChildren(model->indexForItem(item))) {
handler->notifyUpdateStarted(UpdateParameters(iname));
item->setValue(decodeData({}, "notaccessible"));
item->setHasChildren(false);
item->outdated = false;
item->update();
handler->notifyUpdateFinished();
return;
}
// We could legitimately end up here after expanding + closing + re-expaning an item.
}
d->m_lookupRequests.insert(iname);
UpdateParameters params;
params.partialVariable = iname;
doUpdateLocals(params);
}
void DebuggerEngine::updateWatchData(const QString &iname)
{
// This is used in cases where re-evaluation is ok for the same iname
// e.g. when changing the expression in a watcher.
UpdateParameters params;
params.partialVariable = iname;
doUpdateLocals(params);
}
void DebuggerEngine::expandItem(const QString &iname)
{
updateItem(iname);
}
void DebuggerEngine::handleExecDetach()
{
resetLocation();
detachDebugger();
}
void DebuggerEngine::handleExecContinue()
{
resetLocation();
continueInferior();
}
void DebuggerEngine::handleExecInterrupt()
{
resetLocation();
requestInterruptInferior();
}
void DebuggerEngine::handleReset()
{
resetLocation();
resetInferior();
}
void DebuggerEngine::handleExecStep()
{
if (state() == DebuggerNotReady) {
DebuggerRunTool::setBreakOnMainNextTime();
ProjectExplorerPlugin::runStartupProject(ProjectExplorer::Constants::DEBUG_RUN_MODE);
} else {
resetLocation();
if (d->operatesByInstruction())
executeStepI();
else
executeStep();
}
}
void DebuggerEngine::handleExecNext()
{
if (state() == DebuggerNotReady) {
DebuggerRunTool::setBreakOnMainNextTime();
ProjectExplorerPlugin::runStartupProject(ProjectExplorer::Constants::DEBUG_RUN_MODE);
} else {
resetLocation();
if (d->operatesByInstruction())
executeNextI();
else
executeNext();
}
}
void DebuggerEngine::handleExecStepOut()
{
resetLocation();
executeStepOut();
}
void DebuggerEngine::handleExecReturn()
{
resetLocation();
executeReturn();
}
void DebuggerEngine::handleExecJumpToLine()
{
resetLocation();
if (BaseTextEditor *textEditor = BaseTextEditor::currentTextEditor()) {
ContextData location = getLocationContext(textEditor->textDocument(),
textEditor->currentLine());
if (location.isValid())
executeJumpToLine(location);
}
}
void DebuggerEngine::handleExecRunToLine()
{
resetLocation();
if (BaseTextEditor *textEditor = BaseTextEditor::currentTextEditor()) {
ContextData location = getLocationContext(textEditor->textDocument(),
textEditor->currentLine());
if (location.isValid())
executeRunToLine(location);
}
}
void DebuggerEngine::handleExecRunToSelectedFunction()
{
BaseTextEditor *textEditor = BaseTextEditor::currentTextEditor();
QTC_ASSERT(textEditor, return);
QTextCursor cursor = textEditor->textCursor();
QString functionName = cursor.selectedText();
if (functionName.isEmpty()) {
const QTextBlock block = cursor.block();
const QString line = block.text();
foreach (const QString &str, line.trimmed().split(QLatin1Char('('))) {
QString a;
for (int i = str.size(); --i >= 0; ) {
if (!str.at(i).isLetterOrNumber())
break;
a = str.at(i) + a;
}
if (!a.isEmpty()) {
functionName = a;
break;
}
}
}
if (functionName.isEmpty()) {
showMessage(tr("No function selected."), StatusBar);
} else {
showMessage(tr("Running to function \"%1\".").arg(functionName), StatusBar);
resetLocation();
executeRunToFunction(functionName);
}
}
void DebuggerEngine::handleAddToWatchWindow()
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08: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
// Requires a selection, but that's the only case we want anyway.
BaseTextEditor *textEditor = BaseTextEditor::currentTextEditor();
if (!textEditor)
return;
QTextCursor tc = textEditor->textCursor();
QString exp;
if (tc.hasSelection()) {
exp = tc.selectedText();
} else {
int line, column;
exp = cppExpressionAt(textEditor->editorWidget(), tc.position(), &line, &column);
}
if (hasCapability(WatchComplexExpressionsCapability))
exp = removeObviousSideEffects(exp);
else
exp = fixCppExpression(exp);
exp = exp.trimmed();
if (exp.isEmpty()) {
// Happens e.g. when trying to evaluate 'char' or 'return'.
AsynchronousMessageBox::warning(tr("Warning"),
tr("Select a valid expression to evaluate."));
return;
}
watchHandler()->watchVariable(exp);
}
void DebuggerEngine::handleFrameDown()
{
frameDown();
}
void DebuggerEngine::handleFrameUp()
{
frameUp();
}
void DebuggerEngine::checkState(DebuggerState state, const char *file, int line)
{
const DebuggerState current = d->m_state;
if (current == state)
return;
QString msg = QString("UNEXPECTED STATE: %1 WANTED: %2 IN %3:%4")
.arg(stateName(current)).arg(stateName(state)).arg(QLatin1String(file)).arg(line);
showMessage(msg, LogError);
qDebug("%s", qPrintable(msg));
}
bool DebuggerEngine::isNativeMixedEnabled() const
{
return d->m_runParameters.isNativeMixedDebugging();
}
bool DebuggerEngine::isNativeMixedActive() const
{
return isNativeMixedEnabled(); //&& boolSetting(OperateNativeMixed);
}
bool DebuggerEngine::isNativeMixedActiveFrame() const
{
if (!isNativeMixedActive())
return false;
if (stackHandler()->frames().isEmpty())
return false;
StackFrame frame = stackHandler()->frameAt(0);
return frame.language == QmlLanguage;
}
void DebuggerEngine::startDying() const
{
d->m_isDying = true;
if (DebuggerEngine *other = d->m_companionEngine)
other->d->m_isDying = true;
}
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 DebuggerEngine::runId() const
{
return d->m_runId;
}
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 DebuggerRunParameters::isCppDebugging() const
{
return cppEngineType == GdbEngineType
|| cppEngineType == LldbEngineType
|| cppEngineType == CdbEngineType;
}
bool DebuggerRunParameters::isNativeMixedDebugging() const
{
return nativeMixedEnabled && isCppDebugging() && isQmlDebugging;
}
QString DebuggerEngine::formatStartParameters() const
{
const DebuggerRunParameters &sp = d->m_runParameters;
QString rc;
QTextStream str(&rc);
str << "Start parameters: '" << sp.displayName << "' mode: " << sp.startMode
<< "\nABI: " << sp.toolChainAbi.toString() << '\n';
str << "Languages: ";
if (sp.isCppDebugging())
str << "c++ ";
if (sp.isQmlDebugging)
str << "qml";
str << '\n';
if (!sp.inferior.executable.isEmpty()) {
str << "Executable: " << QDir::toNativeSeparators(sp.inferior.executable)
<< ' ' << sp.inferior.commandLineArguments;
if (d->m_terminalRunner)
str << " [terminal]";
str << '\n';
if (!sp.inferior.workingDirectory.isEmpty())
str << "Directory: " << QDir::toNativeSeparators(sp.inferior.workingDirectory)
<< '\n';
}
QString cmd = sp.debugger.executable;
if (!cmd.isEmpty())
str << "Debugger: " << QDir::toNativeSeparators(cmd) << '\n';
if (!sp.coreFile.isEmpty())
str << "Core: " << QDir::toNativeSeparators(sp.coreFile) << '\n';
if (sp.attachPID.isValid())
str << "PID: " << sp.attachPID.pid() << ' ' << sp.crashParameter << '\n';
if (!sp.projectSourceDirectory.isEmpty()) {
FileInProjectFinder/Debugger: Use Utils::FileName for project directory Change-Id: I5a3f376bea4ee06c6856e614f6f71974c2f5ca87 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2018-08-21 17:15:53 +02:00
str << "Project: " << sp.projectSourceDirectory.toUserOutput() << '\n';
FileInProjectFinder/Debugger: Use FileNameList for search directories Change-Id: I8f9fa4631fda26e10e6b21abfcba9e5f74d635c2 Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
2018-08-21 19:03:46 +02:00
str << "Additional Search Directories:";
for (const FileName &dir : sp.additionalSearchDirectories)
str << ' ' << dir;
str << '\n';
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
}
if (!sp.remoteChannel.isEmpty())
str << "Remote: " << sp.remoteChannel << '\n';
if (!sp.qmlServer.host().isEmpty())
str << "QML server: " << sp.qmlServer.host() << ':' << sp.qmlServer.port() << '\n';
str << "Sysroot: " << sp.sysRoot << '\n';
str << "Debug Source Location: " << sp.debugSourceLocation.join(QLatin1Char(':')) << '\n';
return rc;
}
// CppDebuggerEngine
Context CppDebuggerEngine::languageContext() const
{
return Context(Constants::C_CPPDEBUGGER);
}
void CppDebuggerEngine::validateExecutable()
{
DebuggerRunParameters &rp = mutableRunParameters();
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
const bool warnOnRelease = boolSetting(WarnOnReleaseBuilds);
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
bool warnOnInappropriateDebugger = false;
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
QString detailedWarning;
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
switch (rp.toolChainAbi.binaryFormat()) {
Debugger: Remove unneeded qualifications Mostly done using the following ruby script: Dir.glob('**/*.cpp').each { |file| next if file =~ %r{src/shared/qbs|/qmljs/} s = File.read(file) s.scan(/^using namespace (.*);$/) { ns = $1 t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m| before = $1 char = $2 if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/ m else before + char end } if t != s puts file File.open(file, 'w').write(t) end } } Change-Id: I1aa1a2b6ccbafeb1a8f3053fffa39b3f96992591 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-02-03 23:58:49 +02:00
case Abi::PEFormat: {
Debugger: Do no warn when debugging with MinGW Change-Id: Iee9cc2232c002ea960f05848df02ac0658017911 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-07-09 17:03:33 +03:00
QString preferredDebugger;
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
if (rp.toolChainAbi.osFlavor() == Abi::WindowsMSysFlavor) {
if (rp.cppEngineType == CdbEngineType)
Debugger: Do no warn when debugging with MinGW Change-Id: Iee9cc2232c002ea960f05848df02ac0658017911 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-07-09 17:03:33 +03:00
preferredDebugger = "GDB";
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
} else if (rp.cppEngineType != CdbEngineType) {
Debugger: Do no warn when debugging with MinGW Change-Id: Iee9cc2232c002ea960f05848df02ac0658017911 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-07-09 17:03:33 +03:00
// osFlavor() is MSVC, so the recommended debugger is CDB
preferredDebugger = "CDB";
}
if (!preferredDebugger.isEmpty()) {
Debugger: Fix warnings for inappropriate debuggers Change-Id: If463c18d1d04cdd78b6be34e98b76c8df89594f2 Reviewed-by: Robert Loehning <robert.loehning@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-24 14:50:58 +02:00
warnOnInappropriateDebugger = true;
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
detailedWarning = DebuggerEngine::tr(
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
"The inferior is in the Portable Executable format.\n"
Debugger: Do no warn when debugging with MinGW Change-Id: Iee9cc2232c002ea960f05848df02ac0658017911 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-07-09 17:03:33 +03:00
"Selecting %1 as debugger would improve the debugging "
"experience for this binary format.").arg(preferredDebugger);
Debugger: Fix warnings for inappropriate debuggers Change-Id: If463c18d1d04cdd78b6be34e98b76c8df89594f2 Reviewed-by: Robert Loehning <robert.loehning@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-24 14:50:58 +02:00
break;
Debugger: Do no warn when debugging with MinGW Change-Id: Iee9cc2232c002ea960f05848df02ac0658017911 Reviewed-by: hjk <hjk@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io>
2017-07-09 17:03:33 +03: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
if (warnOnRelease && rp.cppEngineType == CdbEngineType) {
if (!rp.symbolFile.endsWith(".exe", Qt::CaseInsensitive))
rp.symbolFile.append(".exe");
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
QString errorMessage;
QStringList rc;
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
if (getPDBFiles(rp.symbolFile, &rc, &errorMessage) && !rc.isEmpty())
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
return;
if (!errorMessage.isEmpty()) {
Debugger: Clean up debuggerengine.cpp Some leftover stringfreeze workaround, plus QLatin1*. Change-Id: I5e143af5cda64cb29b7769174187fc86185a89cb Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2016-06-27 16:40:23 +02:00
detailedWarning.append('\n');
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
detailedWarning.append(errorMessage);
}
} else {
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
return;
}
break;
}
Debugger: Remove unneeded qualifications Mostly done using the following ruby script: Dir.glob('**/*.cpp').each { |file| next if file =~ %r{src/shared/qbs|/qmljs/} s = File.read(file) s.scan(/^using namespace (.*);$/) { ns = $1 t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m| before = $1 char = $2 if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/ m else before + char end } if t != s puts file File.open(file, 'w').write(t) end } } Change-Id: I1aa1a2b6ccbafeb1a8f3053fffa39b3f96992591 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-02-03 23:58:49 +02:00
case Abi::ElfFormat: {
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
if (rp.cppEngineType == CdbEngineType) {
Debugger: Fix warnings for inappropriate debuggers Change-Id: If463c18d1d04cdd78b6be34e98b76c8df89594f2 Reviewed-by: Robert Loehning <robert.loehning@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-24 14:50:58 +02:00
warnOnInappropriateDebugger = true;
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
detailedWarning = DebuggerEngine::tr(
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
"The inferior is in the ELF format.\n"
"Selecting GDB or LLDB as debugger would improve the debugging "
"experience for this binary format.");
Debugger: Fix warnings for inappropriate debuggers Change-Id: If463c18d1d04cdd78b6be34e98b76c8df89594f2 Reviewed-by: Robert Loehning <robert.loehning@qt.io> Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2017-05-24 14:50:58 +02:00
break;
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
}
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08: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
Utils::ElfReader reader(rp.symbolFile);
Debugger: Code cosmetics Sprinkling in const and ranged for. Change-Id: I5d11d57f64140021397c23734c7373544ebebb6f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-05-30 15:42:51 +02:00
const ElfData elfData = reader.readHeaders();
const QString error = reader.errorString();
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08: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
showMessage("EXAMINING " + rp.symbolFile, LogDebug);
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
QByteArray msg = "ELF SECTIONS: ";
Debugger: Cosmetics Qt 5 connects, unused declaration, QLatin1Strings, ... Change-Id: If09929993d750907ee3f4e2fa9f18acfcc28d9c1 Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2016-04-19 22:49:23 +02:00
static const QList<QByteArray> interesting = {
".debug_info",
".debug_abbrev",
".debug_line",
".debug_str",
".debug_loc",
".debug_range",
".gdb_index",
".note.gnu.build-id",
".gnu.hash",
".gnu_debuglink"
};
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
QSet<QByteArray> seen;
Debugger: Code cosmetics Sprinkling in const and ranged for. Change-Id: I5d11d57f64140021397c23734c7373544ebebb6f Reviewed-by: Christian Stenger <christian.stenger@qt.io>
2018-05-30 15:42:51 +02:00
for (const ElfSectionHeader &header : elfData.sectionHeaders) {
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
msg.append(header.name);
msg.append(' ');
if (interesting.contains(header.name))
seen.insert(header.name);
}
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
showMessage(QString::fromUtf8(msg), LogDebug);
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
if (!error.isEmpty()) {
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
showMessage("ERROR WHILE READING ELF SECTIONS: " + error, LogDebug);
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
return;
}
if (elfData.sectionHeaders.isEmpty()) {
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
showMessage("NO SECTION HEADERS FOUND. IS THIS AN EXECUTABLE?", LogDebug);
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
return;
}
// Note: .note.gnu.build-id also appears in regular release builds.
// bool hasBuildId = elfData.indexOf(".note.gnu.build-id") >= 0;
bool hasEmbeddedInfo = elfData.indexOf(".debug_info") >= 0;
bool hasLink = elfData.indexOf(".gnu_debuglink") >= 0;
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
if (hasEmbeddedInfo) {
Debugger: Replace debuggerCore() by equivalent free functions One indirection less on the user code side, and easier to export if needed (partially addressing QTCREATORBUG-13187) Change-Id: I13ab9f471a3a34da7a6331aefc83f6d02413bfab Reviewed-by: David Schulz <david.schulz@digia.com>
2014-10-22 13:04:47 +02:00
QSharedPointer<GlobalDebuggerOptions> options = Internal::globalDebuggerOptions();
Debugger: Support variables for target Useful for e.g. substituting any build dir to current project dir. Change-Id: I50e8c101fa39bd45e55eef65776b18ef76bfd6ad Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-21 09:27:08 +03:00
SourcePathRegExpMap globalRegExpSourceMap;
globalRegExpSourceMap.reserve(options->sourcePathRegExpMap.size());
foreach (auto entry, options->sourcePathRegExpMap) {
MacroExpander: Fall back to global expander ... and use that all over the place. Change-Id: Ie6e0ed0f0d9eaba9b4466761e6b455f33a905086 Reviewed-by: Tobias Hunger <tobias.hunger@theqtcompany.com>
2014-10-15 14:45:31 +02:00
const QString expanded = Utils::globalMacroExpander()->expand(entry.second);
Debugger: Support variables for target Useful for e.g. substituting any build dir to current project dir. Change-Id: I50e8c101fa39bd45e55eef65776b18ef76bfd6ad Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-21 09:27:08 +03:00
if (!expanded.isEmpty())
globalRegExpSourceMap.push_back(qMakePair(entry.first, expanded));
}
if (globalRegExpSourceMap.isEmpty())
return;
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
if (QSharedPointer<Utils::ElfMapper> mapper = reader.readSection(".debug_str")) {
const char *str = mapper->start;
const char *limit = str + mapper->fdlen;
Debugger: Fix crash on regexp matching Conversion of QList to QVector required further adaptations. Instead of trying to match all expressions, break on first match. Change-Id: I76d67ae876687ac15f3099a0a26eac582ad73c76 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-20 23:07:58 +03:00
bool found = false;
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
while (str < limit) {
Debugger: Fix crash on regexp matching Conversion of QList to QVector required further adaptations. Instead of trying to match all expressions, break on first match. Change-Id: I76d67ae876687ac15f3099a0a26eac582ad73c76 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-20 23:07:58 +03:00
const QString string = QString::fromUtf8(str);
for (auto itExp = globalRegExpSourceMap.begin(), itEnd = globalRegExpSourceMap.end();
itExp != itEnd;
++itExp) {
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
QRegExp exp = itExp->first;
int index = exp.indexIn(string);
if (index != -1) {
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
rp.sourcePathMap.insert(string.left(index) + exp.cap(1), itExp->second);
Debugger: Fix crash on regexp matching Conversion of QList to QVector required further adaptations. Instead of trying to match all expressions, break on first match. Change-Id: I76d67ae876687ac15f3099a0a26eac582ad73c76 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-20 23:07:58 +03:00
found = true;
break;
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
}
}
Debugger: Fix crash on regexp matching Conversion of QList to QVector required further adaptations. Instead of trying to match all expressions, break on first match. Change-Id: I76d67ae876687ac15f3099a0a26eac582ad73c76 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-20 23:07:58 +03:00
if (found)
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
break;
Fix excessive warnings by MSVC 2013 64bit about size_t->int truncation C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data Change-Id: I91979c685bbbd84359f7f4e19911a21a408f5d23 Reviewed-by: hjk <hjk@theqtcompany.com>
2015-02-19 16:44:58 +01:00
const int len = int(strlen(str));
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
if (len == 0)
break;
str += len + 1;
}
}
}
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
if (hasEmbeddedInfo || hasLink)
return;
foreach (const QByteArray &name, interesting) {
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
const QString found = seen.contains(name) ? DebuggerEngine::tr("Found.")
: DebuggerEngine::tr("Not found.");
detailedWarning.append('\n' + DebuggerEngine::tr("Section %1: %2").arg(QString::fromUtf8(name)).arg(found));
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08:00
}
break;
}
default:
return;
}
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
if (warnOnInappropriateDebugger) {
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
AsynchronousMessageBox::information(DebuggerEngine::tr("Warning"),
DebuggerEngine::tr("The selected debugger may be inappropriate for the inferior.\n"
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
"Examining symbols and setting breakpoints by file name and line number "
"may fail.\n")
Debugger: Clean up debuggerengine.cpp Some leftover stringfreeze workaround, plus QLatin1*. Change-Id: I5e143af5cda64cb29b7769174187fc86185a89cb Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2016-06-27 16:40:23 +02:00
+ '\n' + detailedWarning);
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
} else if (warnOnRelease) {
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
AsynchronousMessageBox::information(DebuggerEngine::tr("Warning"),
DebuggerEngine::tr("This does not seem to be a \"Debug\" build.\n"
Debugger: Warn on Inappropriate debugger. Change-Id: Ib8777277032c5bd062ffaabd6281b6402576d0fe Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2016-03-11 09:12:12 +01:00
"Setting breakpoints by file name and line number may fail.")
Debugger: Clean up debuggerengine.cpp Some leftover stringfreeze workaround, plus QLatin1*. Change-Id: I5e143af5cda64cb29b7769174187fc86185a89cb Reviewed-by: Orgad Shaneh <orgads@gmail.com>
2016-06-27 16:40:23 +02:00
+ '\n' + detailedWarning);
Debugger: Support setting substitute path by regexp This is useful when there are multiple build machines with different path, and the user would like to match anything up to some known directory to his local project (variable support will also be useful - will try to add that later). Syntax: (/home/.*)/KnownSubdir -> /home/my/project Capture group will be replaced by the value. In this example the substitute path will be (in case a source string found such as /home/SomeUser/SomeProject/KnownSubdir/foo.cpp): /home/SomeUser/SomeProject -> /home/my/project Change-Id: I19d03c9388161d8456a86676086dcb06dc3d7370 Reviewed-by: hjk <hjk121@nokiamail.com>
2014-09-07 23:24:10 +03:00
}
CDB: Warn on release build. Task-number: QTCREATORBUG-8820 Change-Id: If48429fc80d3b928cba4622ff6b168dca8289500 Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com> Reviewed-by: hjk <hjk121@nokiamail.com>
2013-03-04 00:42:36 -08: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
} // 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: reenable disabling of breakpoints in editor context menu
2010-06-25 16:06:48 +02:00
#include "debuggerengine.moc"
Copy Permalink