Starting with F11 and F10 should start with break on main. To know
about the breakpoint, the RunMode parameter needs to be passed.

Change-Id: I0afe9aeb51bccf24aa85d852f5f39f39d9c14db9
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>

This provides a way for third-party plugins to implement run
modes without the need to add a value to the central enum or
using manual workarounds like RunMode(*(int*)&someUniqueObject).

Instead of centrally defined enum values this uses Core::Id that could
be defined anywhere.

Change-Id: Ic350e3d8dbb8042c61b2d4ffec993ca151f53099
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>
Reviewed-by: Eike Ziller <eike.ziller@theqtcompany.com>

- Move sysRoot, debuggerCommand, targetAbi to DebuggerRunParameters,
  they are always the one coming from the kit.
- Move projectSource{Directory,Files} to DebuggerRunParameters,
  they are alway coming from the runConfiguration's project
- Pass RunConfiguration always as separate parameter, that's
  what related code does.

Change-Id: I9965a052237af53fa2d170701bc88b552cab12ed
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>

Allows us to un-export DebuggerRunControlFactory in an attempt to
slim down the publicly visible Debugger plugin interface

Change-Id: I0c2e7351ffa7a9d16586172816635be8ff40172e
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Reviewed-by: David Schulz <david.schulz@theqtcompany.com>
Reviewed-by: Daniel Teske <daniel.teske@theqtcompany.com>

.. to simplify DebuggerRunControlFactory::doCreate() call.

Change-Id: I4dd0c224968bb8a388ea7f095b940b66ee606ab1
Reviewed-by: Christian Stenger <christian.stenger@theqtcompany.com>

Mostly done using the following ruby script:
Dir.glob('**/*.cpp').each { |file|
  next if file =~ %r{src/shared/qbs|/qmljs/}
  s = File.read(file)
  s.scan(/^using namespace (.*);$/) {
    ns = $1
    t = s.gsub(/^(.*)\b#{ns}::((?!Const)[A-Z])/) { |m|
      before = $1
      char = $2
      if before =~ /"|\/\/|\\|using|SIGNAL|SLOT|Q_/
        m
      else
        before + char
      end
    }
    if t != s
      puts file
      File.open(file, 'w').write(t)
    end
  }
}

Change-Id: I919da493d0629b719d328e5e71c96a29d230dfd1
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: hjk <hjk@theqtcompany.com>

Change-Id: I711d5fb475ef814a1dc9d2822740e827f3f67125
Reviewed-by: Alessandro Portale <alessandro.portale@digia.com>

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>

Export factory, de-export plugin, to remove one indirection

Change-Id: I13a46460d07d5ded6b26f2b5ceccd01142fb10e8
Reviewed-by: Christian Stenger <christian.stenger@digia.com>

Change-Id: I3c22ef2685d7aa589f5d0ab74d693653a4c32082
Reviewed-by: Alessandro Portale <alessandro.portale@digia.com>

Change-Id: I2f90c8ae7b5e968b9de882833f8661ab540a9232
Reviewed-by: hjk <hjk121@nokiamail.com>

Use a similar message from Core

Change-Id: Iccdcad0308cb7ac1b674522bce57124e3f0e9086
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Tim Sander <tim@krieglstein.org>

Change-Id: Iea9bd22117133ab55ee6743d0f359808bfaef2aa
Reviewed-by: Tim Sander <tim@krieglstein.org>
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: Ie51847de912748d05a6b208bec82fd612d777202
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>

Change-Id: Idcfdd42f741319f81cc378687451693facdb955f
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I99efd9b9e73efb17bbf3a9f81c5be6c57c325db7
Reviewed-by: Tim Sander <tim@krieglstein.org>
Reviewed-by: hjk <hjk121@nokiamail.com>

Change-Id: I3ea10aa204b1ea41702edab09884b416cd6d9e06
Reviewed-by: Daniel Teske <daniel.teske@digia.com>

Change-Id: Ib5423fdd064e4546f848c0b640b0ed0514c26d3a
Reviewed-by: Leena Miettinen <riitta-leena.miettinen@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>

The current implementation has been tested with a wrongly
configured qmake on windows. But the suffix should not be
appended.

Change-Id: I5f01637698a1fe2dca646eb08ed1b7bd2a1f56a7
Reviewed-by: Christian Kandeler <christian.kandeler@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>

The cleanup goes by the comments found in
https://codereview.qt-project.org/#change,65366,patchset=6


It removes code and comments identified as unneeded.
It also further minimizes the impact on code outside the
plugin dir.

Change-Id: I22bfe9654d0fb6e0bb8f0018ecbe326cda804223
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>

This patch adds the baremetal plugin. The baremetal plugin is for
debugging small targets with hardware debugger where the remote linux
plugin does not fit. It adds a new kit and device class of type
baremetal. The device allows entering custom gdb commands. Currently only
qmake builds are possible. To use this with smaller devices without qt
a fake-qt installation is needed. CMake and qbs is currently not
supported.

Change-Id: I86816f897a2e9ed8b95e3184387969cedf8a14d7
Reviewed-by: hjk <hjk121@nokiamail.com>
Reviewed-by: Tobias Hunger <tobias.hunger@digia.com>