Files
qt-creator/src/plugins/baremetal/debugservers/gdb/stlinkutilgdbserverprovider.cpp

388 lines
13 KiB
C++
Raw Normal View History

BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
/****************************************************************************
**
** Copyright (C) 2016 Denis Shienkov <denis.shienkov@gmail.com>
** Contact: https://www.qt.io/licensing/
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
**
** This file is part of Qt Creator.
**
** 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
** 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.
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00: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.
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
**
****************************************************************************/
#include "stlinkutilgdbserverprovider.h"
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
#include <baremetal/baremetalconstants.h>
#include <baremetal/debugserverprovidermanager.h>
#include <coreplugin/variablechooser.h>
#include <utils/fileutils.h>
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
#include <utils/pathchooser.h>
#include <utils/qtcassert.h>
#include <QCheckBox>
#include <QComboBox>
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
#include <QFormLayout>
#include <QPlainTextEdit>
#include <QSpinBox>
using namespace Utils;
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
namespace BareMetal {
namespace Internal {
const char executableFileKeyC[] = "BareMetal.StLinkUtilGdbServerProvider.ExecutableFile";
const char verboseLevelKeyC[] = "BareMetal.StLinkUtilGdbServerProvider.VerboseLevel";
const char extendedModeKeyC[] = "BareMetal.StLinkUtilGdbServerProvider.ExtendedMode";
const char resetBoardKeyC[] = "BareMetal.StLinkUtilGdbServerProvider.ResetBoard";
const char transportLayerKeyC[] = "BareMetal.StLinkUtilGdbServerProvider.TransportLayer";
// StLinkUtilGdbServerProvider
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
StLinkUtilGdbServerProvider::StLinkUtilGdbServerProvider()
: GdbServerProvider(Constants::STLINK_UTIL_PROVIDER_ID)
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
setInitCommands(defaultInitCommands());
setResetCommands(defaultResetCommands());
setDefaultChannel("localhost", 4242);
setSettingsKeyBase("BareMetal.StLinkUtilGdbServerProvider");
setTypeDisplayName(StLinkUtilGdbServerProviderFactory::tr("ST-LINK Utility"));
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
StLinkUtilGdbServerProvider::StLinkUtilGdbServerProvider(
const StLinkUtilGdbServerProvider &other)
: GdbServerProvider(other)
, m_executableFile(other.m_executableFile)
, m_verboseLevel(0)
, m_extendedMode(false)
, m_resetBoard(true)
, m_transport(RawUsb)
{
}
QString StLinkUtilGdbServerProvider::defaultInitCommands()
{
return {"load\n"};
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
QString StLinkUtilGdbServerProvider::defaultResetCommands()
{
return {};
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
QString StLinkUtilGdbServerProvider::channelString() const
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
switch (startupMode()) {
case NoStartup:
// fallback
case StartupOnNetwork:
// Just return as "host:port" form.
return GdbServerProvider::channelString();
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
case StartupOnPipe:
// Unsupported mode
return {};
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
default: // wrong
return {};
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
}
CommandLine StLinkUtilGdbServerProvider::command() const
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
CommandLine cmd{m_executableFile, {}};
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
if (m_extendedMode)
cmd.addArg("--multi");
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
if (!m_resetBoard)
cmd.addArg("--no-reset");
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
cmd.addArg("--stlink_version=" + QString::number(m_transport));
cmd.addArg("--listen_port=" + QString::number(channel().port()));
cmd.addArg("--verbose=" + QString::number(m_verboseLevel));
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
return cmd;
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
bool StLinkUtilGdbServerProvider::canStartupMode(StartupMode m) const
{
return m == NoStartup || m == StartupOnNetwork;
}
bool StLinkUtilGdbServerProvider::isValid() const
{
if (!GdbServerProvider::isValid())
return false;
const StartupMode m = startupMode();
if (m == NoStartup || m == StartupOnNetwork) {
if (channel().host().isEmpty())
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
return false;
}
if (m == StartupOnNetwork) {
if (m_executableFile.isEmpty())
return false;
}
return true;
}
GdbServerProvider *StLinkUtilGdbServerProvider::clone() const
{
return new StLinkUtilGdbServerProvider(*this);
}
QVariantMap StLinkUtilGdbServerProvider::toMap() const
{
QVariantMap data = GdbServerProvider::toMap();
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
data.insert(executableFileKeyC, m_executableFile.toVariant());
data.insert(verboseLevelKeyC, m_verboseLevel);
data.insert(extendedModeKeyC, m_extendedMode);
data.insert(resetBoardKeyC, m_resetBoard);
data.insert(transportLayerKeyC, m_transport);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
return data;
}
bool StLinkUtilGdbServerProvider::fromMap(const QVariantMap &data)
{
if (!GdbServerProvider::fromMap(data))
return false;
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
m_executableFile = FilePath::fromVariant(data.value(executableFileKeyC));
m_verboseLevel = data.value(verboseLevelKeyC).toInt();
m_extendedMode = data.value(extendedModeKeyC).toBool();
m_resetBoard = data.value(resetBoardKeyC).toBool();
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
m_transport = static_cast<TransportLayer>(
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
data.value(transportLayerKeyC).toInt());
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
return true;
}
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
bool StLinkUtilGdbServerProvider::operator==(const IDebugServerProvider &other) const
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
if (!GdbServerProvider::operator==(other))
return false;
const auto p = static_cast<const StLinkUtilGdbServerProvider *>(&other);
return m_executableFile == p->m_executableFile
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
&& m_verboseLevel == p->m_verboseLevel
&& m_extendedMode == p->m_extendedMode
&& m_resetBoard == p->m_resetBoard
&& m_transport == p->m_transport;
}
GdbServerProviderConfigWidget *StLinkUtilGdbServerProvider::configurationWidget()
{
return new StLinkUtilGdbServerProviderConfigWidget(this);
}
// StLinkUtilGdbServerProviderFactory
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
StLinkUtilGdbServerProviderFactory::StLinkUtilGdbServerProviderFactory()
{
setId(Constants::STLINK_UTIL_PROVIDER_ID);
setDisplayName(tr("ST-LINK Utility"));
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
GdbServerProvider *StLinkUtilGdbServerProviderFactory::create()
{
return new StLinkUtilGdbServerProvider;
}
bool StLinkUtilGdbServerProviderFactory::canRestore(const QVariantMap &data) const
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
const QString id = idFromMap(data);
return id.startsWith(Constants::STLINK_UTIL_PROVIDER_ID + QLatin1Char(':'));
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
GdbServerProvider *StLinkUtilGdbServerProviderFactory::restore(const QVariantMap &data)
{
const auto p = new StLinkUtilGdbServerProvider;
const auto updated = data;
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
if (p->fromMap(updated))
return p;
delete p;
return nullptr;
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
// StLinkUtilGdbServerProviderConfigWidget
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
StLinkUtilGdbServerProviderConfigWidget::StLinkUtilGdbServerProviderConfigWidget(
StLinkUtilGdbServerProvider *p)
: GdbServerProviderConfigWidget(p)
{
Q_ASSERT(p);
m_hostWidget = new HostWidget(this);
m_mainLayout->addRow(tr("Host:"), m_hostWidget);
m_executableFileChooser = new Utils::PathChooser;
m_executableFileChooser->setExpectedKind(Utils::PathChooser::ExistingCommand);
m_mainLayout->addRow(tr("Executable file:"), m_executableFileChooser);
m_verboseLevelSpinBox = new QSpinBox;
m_verboseLevelSpinBox->setRange(0, 99);
m_verboseLevelSpinBox->setToolTip(tr("Specify the verbosity level (0..99)."));
m_mainLayout->addRow(tr("Verbosity level:"), m_verboseLevelSpinBox);
m_extendedModeCheckBox = new QCheckBox;
m_extendedModeCheckBox->setToolTip(tr("Continue listening for connections "
"after disconnect."));
m_mainLayout->addRow(tr("Extended mode:"), m_extendedModeCheckBox);
m_resetBoardCheckBox = new QCheckBox;
m_resetBoardCheckBox->setToolTip(tr("Reset board on connection."));
m_mainLayout->addRow(tr("Reset on connection:"), m_resetBoardCheckBox);
m_transportLayerComboBox = new QComboBox;
m_transportLayerComboBox->setToolTip(tr("Transport layer type."));
m_mainLayout->addRow(tr("Version:"), m_transportLayerComboBox);
m_initCommandsTextEdit = new QPlainTextEdit(this);
m_initCommandsTextEdit->setToolTip(defaultInitCommandsTooltip());
m_mainLayout->addRow(tr("Init commands:"), m_initCommandsTextEdit);
m_resetCommandsTextEdit = new QPlainTextEdit(this);
m_resetCommandsTextEdit->setToolTip(defaultResetCommandsTooltip());
m_mainLayout->addRow(tr("Reset commands:"), m_resetCommandsTextEdit);
populateTransportLayers();
addErrorLabel();
setFromProvider();
const auto chooser = new Core::VariableChooser(this);
chooser->addSupportedWidget(m_initCommandsTextEdit);
chooser->addSupportedWidget(m_resetCommandsTextEdit);
connect(m_hostWidget, &HostWidget::dataChanged,
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
this, &GdbServerProviderConfigWidget::dirty);
connect(m_executableFileChooser, &Utils::PathChooser::rawPathChanged,
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
this, &GdbServerProviderConfigWidget::dirty);
connect(m_verboseLevelSpinBox,
QOverload<int>::of(&QSpinBox::valueChanged),
this, &GdbServerProviderConfigWidget::dirty);
connect(m_extendedModeCheckBox, &QAbstractButton::clicked,
this, &GdbServerProviderConfigWidget::dirty);
connect(m_resetBoardCheckBox, &QAbstractButton::clicked,
this, &GdbServerProviderConfigWidget::dirty);
connect(m_transportLayerComboBox,
QOverload<int>::of(&QComboBox::currentIndexChanged),
this, &GdbServerProviderConfigWidget::dirty);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
connect(m_initCommandsTextEdit, &QPlainTextEdit::textChanged,
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
this, &GdbServerProviderConfigWidget::dirty);
connect(m_resetCommandsTextEdit, &QPlainTextEdit::textChanged,
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
this, &GdbServerProviderConfigWidget::dirty);
connect(m_startupModeComboBox,
QOverload<int>::of(&QComboBox::currentIndexChanged),
this, &StLinkUtilGdbServerProviderConfigWidget::startupModeChanged);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
void StLinkUtilGdbServerProviderConfigWidget::apply()
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
const auto p = static_cast<StLinkUtilGdbServerProvider *>(m_provider);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
Q_ASSERT(p);
p->setChannel(m_hostWidget->channel());
p->m_executableFile = m_executableFileChooser->fileName();
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
p->m_verboseLevel = m_verboseLevelSpinBox->value();
p->m_extendedMode = m_extendedModeCheckBox->isChecked();
p->m_resetBoard = m_resetBoardCheckBox->isChecked();
p->m_transport = transportLayer();
p->setInitCommands(m_initCommandsTextEdit->toPlainText());
p->setResetCommands(m_resetCommandsTextEdit->toPlainText());
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
GdbServerProviderConfigWidget::apply();
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
void StLinkUtilGdbServerProviderConfigWidget::discard()
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
{
setFromProvider();
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
GdbServerProviderConfigWidget::discard();
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
}
StLinkUtilGdbServerProvider::TransportLayer
StLinkUtilGdbServerProviderConfigWidget::transportLayerFromIndex(int idx) const
{
return static_cast<StLinkUtilGdbServerProvider::TransportLayer>(
m_transportLayerComboBox->itemData(idx).toInt());
}
StLinkUtilGdbServerProvider::TransportLayer
StLinkUtilGdbServerProviderConfigWidget::transportLayer() const
{
const int idx = m_transportLayerComboBox->currentIndex();
return transportLayerFromIndex(idx);
}
void StLinkUtilGdbServerProviderConfigWidget::setTransportLayer(
StLinkUtilGdbServerProvider::TransportLayer tl)
{
for (int idx = 0; idx < m_transportLayerComboBox->count(); ++idx) {
if (tl == transportLayerFromIndex(idx)) {
m_transportLayerComboBox->setCurrentIndex(idx);
break;
}
}
}
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
void StLinkUtilGdbServerProviderConfigWidget::startupModeChanged()
{
const GdbServerProvider::StartupMode m = startupMode();
const bool isStartup = m != GdbServerProvider::NoStartup;
m_executableFileChooser->setVisible(isStartup);
m_mainLayout->labelForField(m_executableFileChooser)->setVisible(isStartup);
m_verboseLevelSpinBox->setVisible(isStartup);
m_mainLayout->labelForField(m_verboseLevelSpinBox)->setVisible(isStartup);
m_extendedModeCheckBox->setVisible(isStartup);
m_mainLayout->labelForField(m_extendedModeCheckBox)->setVisible(isStartup);
m_resetBoardCheckBox->setVisible(isStartup);
m_mainLayout->labelForField(m_resetBoardCheckBox)->setVisible(isStartup);
m_transportLayerComboBox->setVisible(isStartup);
m_mainLayout->labelForField(m_transportLayerComboBox)->setVisible(isStartup);
}
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
void StLinkUtilGdbServerProviderConfigWidget::populateTransportLayers()
{
m_transportLayerComboBox->insertItem(
m_transportLayerComboBox->count(), tr("ST-LINK/V1"),
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
StLinkUtilGdbServerProvider::ScsiOverUsb);
m_transportLayerComboBox->insertItem(
m_transportLayerComboBox->count(), tr("ST-LINK/V2"),
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
StLinkUtilGdbServerProvider::RawUsb);
}
void StLinkUtilGdbServerProviderConfigWidget::setFromProvider()
{
BareMetal: Minimize dependency from GDB engine The problem is that this plugin was originally developed only for working with the GDB debugging engine. This hard dependency penetrates to all plugin logic, that excludes an easy addition of other types of a debugger engines. This patch tries to minimize the GDB dependency and improves code a bit in the following way: * A code that belongs to the GDB engine moved to the separate debugservers/gdb directory. * A classes having a common functionality are renamed with 'Debug' suffixes instead of 'Gdb' suffixes. * Introduced a new interface IDebugServerProvider{Factory|ConfigWidget} whih are used as a base for all derived debug servers providers (e.g. for the OpenOCD, STLink and etc). * The IDebugServerProvider interface has a new virtual engineType() method to show a supported debugger engine by a specific debugger server provider. This method is used in BareMetalDebugSupport class to detect a provider engine for an additional initialization (which depends on an used debugger engine). * The IDebugServerProvider interface has a new virtual hasProcess() method. E.g. this is required for a future debug server providers which has not a remote processes. In this case the BareMetalDevice::canCreateProcess() will report about that in a right way. Thus, this approach allowed us to preserve a previous behavior of an already implemented GDB providers. Also it makes possible to add a new providers in a future with a minimized costs. Change-Id: I1be84b9178d4aa78c3ef5108a9e6b381e245f36f Reviewed-by: hjk <hjk@qt.io>
2019-11-04 00:51:58 +03:00
const auto p = static_cast<StLinkUtilGdbServerProvider *>(m_provider);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
Q_ASSERT(p);
const QSignalBlocker blocker(this);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
startupModeChanged();
m_hostWidget->setChannel(p->channel());
m_executableFileChooser->setFileName(p->m_executableFile);
BareMetal: Allow to manage configurations of HW GDB servers The user has only one possibility to setup of the remote GDB server when a new device is created (or to modify it for existing device). It is possible only in the host/port fields for connection to the GDB server. It is a little inconvenient for the user. If the user wants to use other configuration of the GDB server, then need every time to edit the current configuration. Improving this it is introduction a new concept with a new entity named as "GDB server provider". Now to the device debugging purpose the user can choose any of the GDB provider from the list (by analogy with toolchain and so on). Each configuration of GDB provider is created by the user manually on the new "GDB Server Provider" options page. This can be made before or after creation of device. A GDB server provider can work in three startup modes (depends on implementation of concrete provider): 1) NoStartup mode. This means that we do not want to startup a provider, we just trying to connect to the already started GDB provider server. This mode uses the TCP/IP connection with manually specifying of remote host and port. 2) StartupOnNetwork mode. This means that we want to launch of the GDB provider automatically before connect to it in process of remote debugging. This mode also uses the TCP/IP protocol. In addition to it, a GDB provider can has additional options which are contains a paths to provider executable file, to configuration files and so on (it is depends on concrete provider implementation). This mode (with NoStartup) covers about 90% of usecase, and is supported by most set of the GDB server providers. 3) StartupOnPipe mode. This is similar to StartupOnNetwork mode and we also automatically starts the GDB server provider before debugging. But in this case is used the Pipe mode instead of TCP/IP. Not each of the GDB provider can support debugging via pipes. This patch has concrete implementations for a following set of the GDB server providers: * "Default" provider which supports only the NoStartup mode. * "Open On-Chip Debugger" (http://openocd.sourceforge.net/) provider which supports all modes. * "STLinkUtil" (https://github.com/texane/stlink) provider which supports NoStartup and StartupOnNetwork modes. Tested on Windows and Linux with: * target HW: ARM Stm32F4Discovery board with HW debugger STLink-v2 * provider: OpenOCD v0.8.0 (tested on Windows and Linux) * provider: STLink-Util (tested on Linux only) * toolchain: ARM GCC v4.9.2 * debugger: GDB v7.8.1 (with Python support) * QtCreator with QBS project Task-number: QTCREATORBUG-13686 Change-Id: I59c775d91b0a4227d931188879850c536290e1ba Reviewed-by: Leena Miettinen <riitta-leena.miettinen@theqtcompany.com> Reviewed-by: hjk <hjk@theqtcompany.com>
2014-12-20 19:10:02 +00:00
m_verboseLevelSpinBox->setValue(p->m_verboseLevel);
m_extendedModeCheckBox->setChecked(p->m_extendedMode);
m_resetBoardCheckBox->setChecked(p->m_resetBoard);
setTransportLayer(p->m_transport);
m_initCommandsTextEdit->setPlainText(p->initCommands());
m_resetCommandsTextEdit->setPlainText(p->resetCommands());
}
} // namespace Internal
} // namespace ProjectExplorer