Files
qt-creator/src/plugins/baremetal/gdbserverprovider.cpp

478 lines
14 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 "baremetaldevice.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 "gdbserverprovider.h"
#include "gdbserverprovidermanager.h"
#include <utils/environment.h>
#include <utils/qtcassert.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 <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 <QCoreApplication>
#include <QFormLayout>
#include <QLabel>
#include <QLineEdit>
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 <QPlainTextEdit>
#include <QSpinBox>
#include <QUuid>
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 idKeyC[] = "BareMetal.GdbServerProvider.Id";
const char displayNameKeyC[] = "BareMetal.GdbServerProvider.DisplayName";
const char startupModeKeyC[] = "BareMetal.GdbServerProvider.Mode";
const char initCommandsKeyC[] = "BareMetal.GdbServerProvider.InitCommands";
const char resetCommandsKeyC[] = "BareMetal.GdbServerProvider.ResetCommands";
const char useExtendedRemoteKeyC[] = "BareMetal.GdbServerProvider.UseExtendedRemote";
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 char hostKeySuffixC[] = ".Host";
const char portKeySuffixC[] = ".Port";
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
static QString createId(const QString &id)
{
QString newId = id.left(id.indexOf(QLatin1Char(':')));
newId.append(QLatin1Char(':') + QUuid::createUuid().toString());
return newId;
}
// GdbServerProvider
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::GdbServerProvider(const QString &id)
: m_id(createId(id))
{
}
GdbServerProvider::GdbServerProvider(const GdbServerProvider &other)
: m_id(createId(other.m_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
, m_startupMode(other.m_startupMode)
, m_initCommands(other.m_initCommands)
, m_resetCommands(other.m_resetCommands)
, m_useExtendedRemote(other.useExtendedRemote())
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_displayName = QCoreApplication::translate(
"BareMetal::GdbServerProvider", "Clone of %1")
.arg(other.displayName());
}
GdbServerProvider::~GdbServerProvider()
{
const QSet<BareMetalDevice *> devices = m_devices;
for (BareMetalDevice *device : devices)
device->unregisterProvider(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
}
QString GdbServerProvider::displayName() const
{
if (m_displayName.isEmpty())
return typeDisplayName();
return m_displayName;
}
void GdbServerProvider::setDisplayName(const QString &name)
{
if (m_displayName == name)
return;
m_displayName = name;
providerUpdated();
}
QString GdbServerProvider::id() const
{
return m_id;
}
GdbServerProvider::StartupMode GdbServerProvider::startupMode() const
{
return m_startupMode;
}
void GdbServerProvider::setStartupMode(StartupMode m)
{
m_startupMode = m;
}
QString GdbServerProvider::initCommands() const
{
return m_initCommands;
}
void GdbServerProvider::setInitCommands(const QString &cmds)
{
m_initCommands = cmds;
}
bool GdbServerProvider::useExtendedRemote() const
{
return m_useExtendedRemote;
}
QString GdbServerProvider::typeDisplayName() const
{
return m_typeDisplayName;
}
void GdbServerProvider::setUseExtendedRemote(bool useExtendedRemote)
{
m_useExtendedRemote = useExtendedRemote;
}
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 GdbServerProvider::resetCommands() const
{
return m_resetCommands;
}
void GdbServerProvider::setResetCommands(const QString &cmds)
{
m_resetCommands = cmds;
}
void GdbServerProvider::setChannel(const QUrl &channel)
{
m_channel = channel;
}
void GdbServerProvider::setDefaultChannel(const QString &host, int port)
{
m_channel.setHost(host);
m_channel.setPort(port);
}
QUrl GdbServerProvider::channel() const
{
return m_channel;
}
Utils::CommandLine GdbServerProvider::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
{
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
}
bool GdbServerProvider::operator==(const GdbServerProvider &other) const
{
if (this == &other)
return true;
const QString thisId = id().left(id().indexOf(QLatin1Char(':')));
const QString otherId = other.id().left(other.id().indexOf(QLatin1Char(':')));
// We ignore displayname
return thisId == otherId
&& m_channel == other.m_channel
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_startupMode == other.m_startupMode
&& m_initCommands == other.m_initCommands
&& m_resetCommands == other.m_resetCommands
&& m_useExtendedRemote == other.m_useExtendedRemote;
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 GdbServerProvider::channelString() const
{
// Just return as "host:port" form.
if (m_channel.port() <= 0)
return m_channel.host();
return m_channel.host() + ':' + QString::number(m_channel.port());
}
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
QVariantMap GdbServerProvider::toMap() const
{
return {
{QLatin1String(idKeyC), m_id},
{QLatin1String(displayNameKeyC), m_displayName},
{QLatin1String(startupModeKeyC), m_startupMode},
{QLatin1String(initCommandsKeyC), m_initCommands},
{QLatin1String(resetCommandsKeyC), m_resetCommands},
{QLatin1String(useExtendedRemoteKeyC), m_useExtendedRemote},
{m_settingsBase + hostKeySuffixC, m_channel.host()},
{m_settingsBase + portKeySuffixC, m_channel.port()},
};
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 GdbServerProvider::isValid() const
{
return !channelString().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
}
bool GdbServerProvider::canStartupMode(StartupMode m) const
{
return m == NoStartup;
}
void GdbServerProvider::registerDevice(BareMetalDevice *device)
{
m_devices.insert(device);
}
void GdbServerProvider::unregisterDevice(BareMetalDevice *device)
{
m_devices.remove(device);
}
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 GdbServerProvider::providerUpdated()
{
GdbServerProviderManager::notifyAboutUpdate(this);
for (BareMetalDevice *device : qAsConst(m_devices))
device->providerUpdated(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
}
bool GdbServerProvider::fromMap(const QVariantMap &data)
{
m_id = data.value(QLatin1String(idKeyC)).toString();
m_displayName = data.value(QLatin1String(displayNameKeyC)).toString();
m_startupMode = static_cast<StartupMode>(data.value(QLatin1String(startupModeKeyC)).toInt());
m_initCommands = data.value(QLatin1String(initCommandsKeyC)).toString();
m_resetCommands = data.value(QLatin1String(resetCommandsKeyC)).toString();
m_useExtendedRemote = data.value(QLatin1String(useExtendedRemoteKeyC)).toBool();
m_channel.setHost(data.value(m_settingsBase + hostKeySuffixC).toString());
m_channel.setPort(data.value(m_settingsBase + portKeySuffixC).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;
}
void GdbServerProvider::setTypeDisplayName(const QString &typeDisplayName)
{
m_typeDisplayName = typeDisplayName;
}
void GdbServerProvider::setSettingsKeyBase(const QString &settingsBase)
{
m_settingsBase = settingsBase;
}
// GdbServerProviderFactory
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 GdbServerProviderFactory::id() const
{
return m_id;
}
void GdbServerProviderFactory::setId(const QString &id)
{
m_id = id;
}
QString GdbServerProviderFactory::displayName() const
{
return m_displayName;
}
void GdbServerProviderFactory::setDisplayName(const QString &name)
{
m_displayName = name;
}
QString GdbServerProviderFactory::idFromMap(const QVariantMap &data)
{
return data.value(QLatin1String(idKeyC)).toString();
}
void GdbServerProviderFactory::idToMap(QVariantMap &data, const QString &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
{
data.insert(QLatin1String(idKeyC), id);
}
// GdbServerProviderConfigWidget
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
GdbServerProviderConfigWidget::GdbServerProviderConfigWidget(
GdbServerProvider *provider)
: m_provider(provider)
{
Q_ASSERT(provider);
m_mainLayout = new QFormLayout(this);
m_mainLayout->setFieldGrowthPolicy(QFormLayout::ExpandingFieldsGrow);
m_nameLineEdit = new QLineEdit(this);
m_nameLineEdit->setToolTip(tr("Enter the name of the GDB server provider."));
m_mainLayout->addRow(tr("Name:"), m_nameLineEdit);
m_startupModeComboBox = new QComboBox(this);
m_startupModeComboBox->setToolTip(tr("Choose the desired startup mode "
"of the GDB server provider."));
m_mainLayout->addRow(tr("Startup mode:"), m_startupModeComboBox);
populateStartupModes();
setFromProvider();
connect(m_nameLineEdit, &QLineEdit::textChanged,
this, &GdbServerProviderConfigWidget::dirty);
connect(m_startupModeComboBox,
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
}
void GdbServerProviderConfigWidget::apply()
{
m_provider->setDisplayName(m_nameLineEdit->text());
m_provider->setStartupMode(startupMode());
applyImpl();
}
void GdbServerProviderConfigWidget::discard()
{
m_nameLineEdit->setText(m_provider->displayName());
discardImpl();
}
GdbServerProvider *GdbServerProviderConfigWidget::provider() const
{
return m_provider;
}
void GdbServerProviderConfigWidget::addErrorLabel()
{
if (!m_errorLabel) {
m_errorLabel = new QLabel;
m_errorLabel->setVisible(false);
}
m_mainLayout->addRow(m_errorLabel);
}
GdbServerProvider::StartupMode GdbServerProviderConfigWidget::startupModeFromIndex(
int idx) const
{
return static_cast<GdbServerProvider::StartupMode>(
m_startupModeComboBox->itemData(idx).toInt());
}
GdbServerProvider::StartupMode GdbServerProviderConfigWidget::startupMode() const
{
const int idx = m_startupModeComboBox->currentIndex();
return startupModeFromIndex(idx);
}
void GdbServerProviderConfigWidget::setStartupMode(GdbServerProvider::StartupMode m)
{
for (int idx = 0; idx < m_startupModeComboBox->count(); ++idx) {
if (m == startupModeFromIndex(idx)) {
m_startupModeComboBox->setCurrentIndex(idx);
break;
}
}
}
void GdbServerProviderConfigWidget::populateStartupModes()
{
for (int i = 0; i < GdbServerProvider::StartupModesCount; ++i) {
const auto m = static_cast<GdbServerProvider::StartupMode>(i);
if (!m_provider->canStartupMode(m))
continue;
const int idx = m_startupModeComboBox->count();
m_startupModeComboBox->insertItem(
idx,
(m == GdbServerProvider::NoStartup)
? tr("No Startup")
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 == GdbServerProvider::StartupOnNetwork)
? tr("Startup in TCP/IP Mode")
: tr("Startup in Pipe Mode")),
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);
}
}
void GdbServerProviderConfigWidget::setErrorMessage(const QString &m)
{
QTC_ASSERT(m_errorLabel, return);
if (m.isEmpty()) {
clearErrorMessage();
} else {
m_errorLabel->setText(m);
m_errorLabel->setStyleSheet(QLatin1String("background-color: \"red\""));
m_errorLabel->setVisible(true);
}
}
void GdbServerProviderConfigWidget::clearErrorMessage()
{
QTC_ASSERT(m_errorLabel, return);
m_errorLabel->clear();
m_errorLabel->setStyleSheet(QString());
m_errorLabel->setVisible(false);
}
void GdbServerProviderConfigWidget::setFromProvider()
{
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
m_nameLineEdit->setText(m_provider->displayName());
setStartupMode(m_provider->startupMode());
}
QString GdbServerProviderConfigWidget::defaultInitCommandsTooltip()
{
return QCoreApplication::translate("BareMetal",
"Enter GDB commands to reset the board "
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
"and to write the nonvolatile memory.");
}
QString GdbServerProviderConfigWidget::defaultResetCommandsTooltip()
{
return QCoreApplication::translate("BareMetal",
"Enter GDB commands to reset the hardware. "
"The MCU should be halted after these commands.");
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
}
// HostWidget
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
HostWidget::HostWidget(QWidget *parent)
: QWidget(parent)
{
m_hostLineEdit = new QLineEdit(this);
m_hostLineEdit->setToolTip(tr("Enter TCP/IP hostname of the GDB server provider, "
"like \"localhost\" or \"192.0.2.1\"."));
m_portSpinBox = new QSpinBox(this);
m_portSpinBox->setRange(0, 65535);
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_portSpinBox->setToolTip(tr("Enter TCP/IP port which will be listened by "
"the GDB server provider."));
const auto layout = new QHBoxLayout(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
layout->setContentsMargins(0, 0, 0, 0);
layout->addWidget(m_hostLineEdit);
layout->addWidget(m_portSpinBox);
connect(m_hostLineEdit, &QLineEdit::textChanged,
this, &HostWidget::dataChanged);
connect(m_portSpinBox, QOverload<int>::of(&QSpinBox::valueChanged),
this, &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
}
void HostWidget::setChannel(const QUrl &channel)
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 QSignalBlocker blocker(this);
m_hostLineEdit->setText(channel.host());
m_portSpinBox->setValue(channel.port());
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
}
QUrl HostWidget::channel() 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
{
QUrl url;
url.setHost(m_hostLineEdit->text());
url.setPort(m_portSpinBox->value());
return url;
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 Internal
} // namespace BareMetal