Freigeben über


Konfigurieren von CMake-Debugsitzungen

Die native Unterstützung für CMake ist in Visual Studio 2017 und höher verfügbar. Um die Dokumentation für diese Versionen anzuzeigen, legen Sie das Auswahlsteuerelement Version in Visual Studio für diesen Artikel auf Visual Studio 2017 oder höher fest. Es befindet sich am Anfang des Inhaltsverzeichnisses auf dieser Seite.

Alle ausführbaren CMake-Ziele werden in der Dropdownliste Startelement in der Symbolleiste angezeigt. Wählen Sie eine Version aus, um eine Debugsitzung und somit den Debugger zu starten.

Screenshot der Dropdownliste der CMake-Startobjekte.

Das Dropdownmenü bietet eine Liste von Debugzielen zur Auswahl. Das ausgewählte Element erscheint als Wiedergabe-Schaltfläche gefolgt vom Namen des ausgewählten Debugziels, das ausgeführt werden soll. In diesem Beispiel ist das ausgewählte Debugziel Hallo Welt .exe.

Sie können eine Debugsitzung auch über den Projektmappen-Explorer starten. Wechseln Sie zunächst zur Ansicht CMake-Zielansicht im Fenster Projektmappen-Explorer.

Screenshot der CMake-Ziele-Ansicht Menü.

Der Projektmappen-Explorer wird angezeigt. Ein Klick mit der rechten Maustaste auf ein Element in der Ordneransicht hat ein Menü geöffnet, das Optionen wie Öffnen, Öffnen mit, Vergleichen und so weiter anzeigt. Das Menüelement „Switch zu Zielansicht“ ist hervorgehoben.

Klicken Sie dann mit der rechten Maustaste auf eine ausführbare Datei und dann auf Debuggen. Mit diesem Befehl wird das Debuggen des ausgewählten Ziels basierend auf der aktiven Konfiguration automatisch gestartet.

Screenshot der Menüoption für das Debuggen in der CMake-Zielansicht.

Ein Rechtsklick auf ein Ziel in der CMake-Zielansicht hat ein Menü mit Optionen wie Als Starten-Element festlegen, Erstellen, Alles löschen usw. geöffnet. Die Debug-Menüoption ist hervorgehoben.

Ab Visual Studio Version 2022 17.6 können Sie auch eine Debugsitzung für Ihre CMakeLists.txt-Datei starten. Um dies zu tun, setzen Sie einfach einen Haltepunkt in Ihrer CMakeLists.txt-Datei und führen Sie „Projekt mit CMake Debugger konfigurieren“ aus dem Dropdown-Menü „Projekt“ aus.

Screenshot des Dropdownmenüs des CMake-Debuggers.

Die Dropdownliste „Projekt“ wird angezeigt. Die Menüoption zum Konfigurieren des Projekts mit dem CMake-Debugger ist hervorgehoben.

Anpassen von Debuggereinstellungen

Sie können die Debuggereinstellungen für alle ausführbaren CMake-Ziele im Projekt anpassen. Sie befinden sich in einer Konfigurationsdatei namens launch.vs.json, die sich in einem .vs Ordner im Stammverzeichnis Ihres Projekts befindet. Eine Startkonfigurationsdatei ist in den meisten Debugszenarios nützlich, da Sie die Details zum Debuggen konfigurieren und speichern können. Es gibt drei Einstiegspunkte für diese Datei:

  • Debuggen-Menü Wählen Sie Debug > Debug- und Start-Einstellungen für ${activeDebugTarget} im Hauptmenü aus, um die Debug-Konfiguration speziell für Ihr aktives Debugziel anzupassen. Wenn Sie kein Debugziel ausgewählt haben, ist diese Option ausgegraut.

Screenshot des Menübefehls „Debuggen“: Debug- und Starteinstellungen für das Projekt.

  • Ziele-Sicht Navigieren Sie zu Ansicht Ziele im Projektmappen-Explorer. Klicken Sie dann mit der rechten Maustaste auf ein Debugziel und dann auf Add Debug Configuration (Debugkonfiguration hinzufügen), um die für das Debugziel spezifische Debugkonfiguration anzupassen.

Screenshot des Befehls zum Hinzufügen der Debugkonfiguration im Kontextmenü für das Ziel.

  • Stamm-CMakeLists.txt Klicken Sie mit der rechten Maustaste auf eine Stamm-CMakeLists.txt und aktivieren Sie Debug-Konfiguration hinzufügen, um das Dialogfeld Debugger auswählen zu öffnen. Mit dem Dialogfeld können Sie jeden beliebigen Typ der Debugkonfiguration hinzufügen. Sie müssen das CMake-Ziel jedoch manuell angeben, um dieses über die projectTarget-Eigenschaft aufzurufen.

Screenshot: Dialogfeld „Debugger auswählen“.

Sie können die launch.vs.json-Datei bearbeiten, um Debugkonfigurationen für eine beliebige Anzahl von CMake-Zielen zu erstellen. Wenn Sie die Datei speichern, erstellt Visual Studio im Dropdownmenü Startelement einen Eintrag für jede neue Konfiguration.

Verweisschlüssel in CMakeSettings.json

Stellen Sie in der launch.vs.json-Datei cmake. voran, um in einer CMakeSettings.json-Datei auf einen beliebigen Schlüssel zu verweisen. In folgendem Beispiel wird eine einfache launch.vs.json-Datei dargestellt, die den Wert des Schlüssels remoteCopySources aus der Datei CMakeSettings.json für die derzeit ausgewählte Konfiguration abruft:

{
  "version": "0.2.1",
  "configurations": [
    {
      "type": "default",
      "project": "CMakeLists.txt",
      "projectTarget": "CMakeHelloWorld.exe (Debug\\CMakeHelloWorld.exe)",
      "name": "CMakeHelloWorld.exe (Debug\\CMakeHelloWorld.exe)",
      "args": ["${cmake.remoteCopySources}"]
    }
  ]
}

Umgebungsvariablen definiert in CMakeSettings.json können auch in launch.vs.json mit der Syntax ${env.VARIABLE_NAME} verwendet werden. In Visual Studio 2019, Version 16.4 und höher werden Debugziele mithilfe der in der CMakeSettings.json-Datei angegebenen Umgebung automatisch gestartet. Sie können eine Umgebungsvariable zurücksetzen, indem Sie sie auf Null festlegen.

Launch.vs.json-Verweis

Es gibt viele launch.vs.json-Eigenschaften, die alle Debugszenarios unterstützen. Die folgenden Eigenschaften gelten sowohl für alle lokalen als auch für Remotedebugkonfigurationen:

  • projectTarget: Gibt das CMake-Ziel an, das beim Erstellen des Projekts aufgerufen werden soll. Visual Studio füllt diese Eigenschaft automatisch auf, wenn Sie launch.vs.json im Menü „Debuggen“ oder in der Targets View (Zielansicht) eingeben. Dieser Wert muss mit dem Namen eines vorhandenen Debugziels übereinstimmen, das im Dropdownmenü Startelement aufgeführt wird.

  • env: Zusätzliche Umgebungsvariablen zum Hinzufügen unter Verwendung der Syntax:

    "env": {
          "DEBUG_LOGGING_LEVEL": "trace;info",
          "ENABLE_TRACING": "true"
        }
    
  • args: Befehlszeilenargumente, die an das Programm zum Debuggen übergeben werden

Launch.vs.json-Verweis für Remoteprojekte und WSL

In Visual 2019, Version 16.6 haben wir eine neue Debugkonfiguration von type: cppgdb hinzugefügt, um das Debuggen auf Remotesystemen und WSL zu vereinfachen. Alte Debugkonfigurationen von type: cppdbg werden weiterhin unterstützt.

Konfigurationstyp cppgdb

  • name: Ein Anzeigename zur Identifikation der Konfiguration im Startup-Element Dropdown.
  • project: Gibt den relativen Pfad zur Projektdatei an. Normalerweise müssen Sie diesen Pfad beim Debuggen eines CMake-Projekts nicht ändern.
  • projectTarget: Gibt das CMake-Ziel an, das beim Erstellen des Projekts aufgerufen werden soll. Visual Studio füllt diese Eigenschaft automatisch auf, wenn Sie launch.vs.json im Menü „Debuggen“ oder in der Targets View (Zielansicht) eingeben. Dieser Zielwert muss mit dem Namen eines vorhandenen Debugziels übereinstimmen, das im Dropdownmenü Startelement aufgeführt wird.
  • debuggerConfiguration: Gibt an, welche Menge von Debugging-Standardwerten verwendet werden soll. In Visual Studio 2019, Version 16.6 ist gdb die einzige gültige Option. Visual Studio 2019, Version 16.7 oder höher, bietet ebenfalls Unterstützung für gdbserver.
  • args: Befehlszeilenargumente, die beim Starten an das zu debuggende Programm übergeben werden.
  • env: Zusätzliche Umgebungsvariablen, die an das zu debuggende Programm übergeben werden. Beispiel: {"DISPLAY": "0.0"}.
  • processID: Linux-Prozess-ID zum Anfügen. Diese wird nur beim Anhängen an einen Remoteprozess verwendet. Weitere Informationen finden Sie unter Problembehandlung beim Anhängen an Prozesse mithilfe von gdb.

Zusätzliche Optionen für die gdb-Konfiguration

  • program: Standardmäßig "${debugInfo.fullTargetPath}". Dies ist der UNIX-Pfad zu der zu debuggenden Anwendung. Dieser ist nur erforderlich, wenn dieser von dem der ausführbaren Zieldatei im Build- oder Bereitstellungsspeicherort abweicht.
  • remoteMachineName: Standardmäßig "${debugInfo.remoteMachineName}" . Dies ist der Name des Remotesystems, das das zu debuggende Programm hostet. Dieser ist nur erforderlich, wenn er von dem des Buildsystems abweicht. Im Verbindungs-Manager muss ein Eintrag vorhanden sein. Drücken Sie STRG+LEERTASTE, um eine Liste aller vorhandenen Remoteverbindungen anzuzeigen.
  • cwd: Standardmäßig "${debugInfo.defaultWorkingDirectory}" . Dies ist der UNIX-Pfad zum Verzeichnis auf dem Remotesystem, auf dem program ausgeführt wird. Das Verzeichnis muss vorhanden sein.
  • gdbpath: Standardmäßig /usr/bin/gdb . Dies ist der vollständige UNIX-Pfad zu dem zum Debuggen verwendeten gdb-Befehl. Dieser ist nur erforderlich, wenn eine benutzerdefinierte Version von gdb verwendet wird.
  • preDebugCommand: Ein Linux-Befehl, der unmittelbar vor dem Aufrufen von gdb ausgeführt wird. gdb startet erst, wenn der Befehl abgeschlossen ist. Sie können die Option verwenden, um ein Skript vor der Ausführung von gdb auszuführen.

Mit der gdbserver-Konfiguration (16.7 oder höher) sind weitere Optionen zulässig.

  • program: Standardmäßig "${debugInfo.fullTargetPath}". Dies ist der UNIX-Pfad zu der zu debuggenden Anwendung. Dieser ist nur erforderlich, wenn dieser von dem der ausführbaren Zieldatei im Build- oder Bereitstellungsspeicherort abweicht.

    Tipp

    Für lokale Kreuzkompilierungsszenarios wird die Bereitstellung noch nicht unterstützt. Wenn Sie unter Windows eine Kreuzkompilierung durchführen (z. B. wenn Sie mit einem Kreuzcompiler unter Windows eine ausführbare ARM-Datei für Linux erstellen), müssen Sie die Binärdatei vor dem Debuggen manuell an den bei program angegebenen Speicherort auf dem ARM-Remotecomputer kopieren.

  • remoteMachineName: Standardmäßig "${debugInfo.remoteMachineName}" . Dies ist der Name des Remotesystems, das das zu debuggende Programm hostet. Dieser ist nur erforderlich, wenn er von dem des Buildsystems abweicht. Im Verbindungs-Manager muss ein Eintrag vorhanden sein. Drücken Sie STRG+LEERTASTE, um eine Liste aller vorhandenen Remoteverbindungen anzuzeigen.

  • cwd: Standardmäßig "${debugInfo.defaultWorkingDirectory}" . Dies ist der vollständige UNIX-Pfad zum Verzeichnis auf dem Remotesystem, auf dem program ausgeführt wird. Das Verzeichnis muss vorhanden sein.

  • gdbPath: Vollständiger Windows-Pfad zum gdb, der zum Debuggen verwendet wird.

  • gdbserverPath: Standardmäßig usr/bin/gdbserver . Dies ist der vollständige UNIX-Pfad zu dem zum Debuggen verwendeten gdbserver-Befehl.

  • preDebugCommand: Ein Linux-Befehl, der unmittelbar vor dem Starten von „gdbserver“ auszuführen ist. gdbserver startet nicht, bis der Befehl abgeschlossen ist.

Bereitstellungsoptionen

Verwenden Sie die folgenden Optionen, um den (in der CMakeSettings.json-Datei definierten) Buildcomputer vom Remotedebugcomputer zu trennen.

  • remoteMachineName: Remotedebuggen des Remotecomputers. Dieser ist nur erforderlich, wenn er von dem des Buildcomputers abweicht. Im Verbindungs-Manager muss ein Eintrag vorhanden sein. Drücken Sie STRG+LEERTASTE, um eine Liste aller vorhandenen Remoteverbindungen anzuzeigen.
  • disableDeploy: Standardmäßig false . Hiermit wird angegeben, ob die Build- bzw. Debugtrennung deaktiviert ist. Im Falle von false ermöglicht diese Option das Durchführen von Build- und Debugvorgängen auf zwei separaten Computern.
  • deployDirectory: Vollständiger UNIX-Pfad zu dem Verzeichnis auf remoteMachineName, in das die ausführbare Datei kopiert wird.
  • deploy: Eine Matrix erweiterter Bereitstellungseinstellungen. Sie müssen diese Einstellungen nur konfigurieren, wenn Sie genauere Kontrolle über den Bereitstellungsprozess wünschen. Standardmäßig werden nur die Dateien, die für den zu debuggenden Prozess erforderlich sind, auf dem Remotedebugcomputer bereitgestellt.
    • sourceMachine: Der Computer, von dem die Datei oder das Verzeichnis kopiert wird. Drücken Sie STRG+LEERTASTE, um eine Liste aller im Verbindungs-Manager gespeicherten Remoteverbindungen anzuzeigen. Wenn Sie nativ auf WSL aufbauen, wird diese Option ignoriert.
    • targetMachine: Der Computer, auf den die Datei oder das Verzeichnis kopiert wird. Drücken Sie STRG+LEERTASTE, um eine Liste aller im Verbindungs-Manager gespeicherten Remoteverbindungen anzuzeigen.
    • sourcePath: Der Datei- oder Verzeichnisspeicherort auf „sourceMachine“.
    • targetPath: Der Datei- oder Verzeichnisspeicherort auf „targetMachine“.
    • deploymentType: Eine Beschreibung des Bereitstellungstyps. LocalRemote UND RemoteRemote werden unterstützt. LocalRemote bedeutet, dass vom lokalen Dateisystem zum Remotesystem kopiert wird, das durch remoteMachineName in launch.vs.json angegeben ist. RemoteRemote bedeutet das Kopieren vom Remotebuildserver, der in CMakeSettings.json angegeben ist, zu dem anderen Remotesystem, das in Start.vs.json angegeben ist.
    • executable: Gibt an, ob die bereitgestellte Datei ausführbar ist.

Ausführen benutzerdefinierter gdb-Befehle

Visual Studio unterstützt das Ausführen von benutzerdefinierten gdb-Befehlen, um direkt mit dem zugrunde liegenden Debugger zu interagieren. Weitere Informationen finden Sie unter Ausführen benutzerdefinierter -lldb-Befehlegdb.

Aktivieren der Protokollierung

Aktivieren Sie die MIEngine-Protokollierung, um anzuzeigen, welche Befehle an gdb gesendet werden, welche Ausgabe gdb zurückgibt und wie lange die einzelnen Befehle dauern. Erfahren Sie mehr

Konfigurationstyp cppdbg

Die folgenden Optionen können beim Debuggen auf einem Remotesystem oder WSL mit dem Konfigurationstyp cppdbg verwendet werden. In Visual Studio 2019, Version 16.6 oder höher wird der Konfigurationstyp cppgdb empfohlen.

  • name: Ein Anzeigename zur Identifikation der Konfiguration im Startup-Element Dropdown.

  • project: Gibt den relativen Pfad zur Projektdatei an. Normalerweise müssen Sie diesen Wert beim Debuggen eines CMake-Projekts nicht ändern.

  • projectTarget: Gibt das CMake-Ziel an, das beim Erstellen des Projekts aufgerufen werden soll. Visual Studio füllt diese Eigenschaft automatisch auf, wenn Sie launch.vs.json im Menü „Debuggen“ oder in der Targets View (Zielansicht) eingeben. Dieser Wert muss mit dem Namen eines vorhandenen Debugziels übereinstimmen, das im Dropdownmenü Startelement aufgeführt wird.

  • args: Befehlszeilenargumente, die beim Starten an das zu debuggende Programm übergeben werden.

  • processID: Linux-Prozess-ID zum Anfügen. Diese wird nur beim Anhängen an einen Remoteprozess verwendet. Weitere Informationen finden Sie unter Problembehandlung beim Anhängen an Prozesse mithilfe von gdb.

  • program: Standardmäßig "${debugInfo.fullTargetPath}". Dies ist der UNIX-Pfad zu der zu debuggenden Anwendung. Dieser ist nur erforderlich, wenn dieser von dem der ausführbaren Zieldatei im Build- oder Bereitstellungsspeicherort abweicht.

  • remoteMachineName: Standardmäßig "${debugInfo.remoteMachineName}" . Dies ist der Name des Remotesystems, das das zu debuggende Programm hostet. Dieser ist nur erforderlich, wenn er von dem des Buildsystems abweicht. Im Verbindungs-Manager muss ein Eintrag vorhanden sein. Drücken Sie STRG+LEERTASTE, um eine Liste aller vorhandenen Remoteverbindungen anzuzeigen.

  • cwd: Standardmäßig "${debugInfo.defaultWorkingDirectory}" . Dies ist der vollständige UNIX-Pfad zum Verzeichnis auf dem Remotesystem, auf dem program ausgeführt wird. Das Verzeichnis muss vorhanden sein.

  • environment: Zusätzliche Umgebungsvariablen, die an das zu debuggende Programm übergeben werden. Beispiel:

      "environment": [
          {
            "name": "ENV1",
            "value": "envvalue1"
          },
          {
            "name": "ENV2",
            "value": "envvalue2"
          }
        ]
    
  • pipeArgs: Ein Array von Befehlszeilenargumenten, die an das senkrechter Strich-Programm übergeben werden, um die Verbindung zu konfigurieren. Das Pipeprogramm wird verwendet, um Standardeingaben und -ausgaben zwischen Visual Studio und gdb weiterzuleiten. Beim Debuggen von CMake-Projekten muss ein Großteil dieses Arrays nicht angepasst werden. ${debuggerCommand} bildet die Ausnahme, da hiermit gdb auf dem Remotesystem gestartet wird. Dies kann wie folgt geändert werden:

    • Exportieren Sie den Wert der Umgebungsvariablen „DISPLAY“ auf Ihrem Linux-System. Im folgenden Beispiel lautet dieser Wert :1.

      "pipeArgs": [
          "/s",
          "${debugInfo.remoteMachineId}",
          "/p",
          "${debugInfo.parentProcessId}",
          "/c",
          "export DISPLAY=:1;${debuggerCommand}",
          "--tty=${debugInfo.tty}"
        ],
      
    • Führen Sie vor der Ausführung von gdb ein Skript aus. Stellen Sie sicher, dass die Ausführungsberechtigungen für Ihr Skript festgelegt sind.

      "pipeArgs": [
          "/s",
          "${debugInfo.remoteMachineId}",
          "/p",
          "${debugInfo.parentProcessId}",
          "/c",
          "/path/to/script.sh;${debuggerCommand}",
          "--tty=${debugInfo.tty}"
        ],
      
  • stopOnEntry: Ein boolesch, das angibt, ob der Prozess sofort beim Start unterbrochen werden soll. Die Standardeinstellung ist „false“.

  • visualizerFile: Eine .natvis-Datei zur Nutzung beim Debuggen dieses Prozesses. Diese Option ist nicht mit der automatischen Strukturierung und Einrückung von gdb kompatibel. Legen Sie auch showDisplayString fest, wenn Sie diese Eigenschaft festlegen.

  • showDisplayString: Ein boolesch, das die Zeichenfolge anzeigen aktiviert, wenn ein visualizerFile angegeben ist. Wenn diese Option auf true festgelegt wird, kann die Leistung beim Debuggen verlangsamt werden.

  • setupCommands: Ein oder mehrere gdb Befehl(e) zum Ausführen, um den zugrunde liegenden Debugger einzurichten.

  • miDebuggerPath: Der vollständige Pfad zu gdb. Wenn dieser nicht angegeben ist, sucht Visual Studio zuerst nach dem Pfad für den Debugger.

  • Schließlich können auch alle Bereitstellungsoptionen, die für den Konfigurationstyp cppgdb definiert sind, vom Konfigurationstyp cppdbg verwendet werden.

Debuggen mithilfe von gdbserver

Sie können die cppdbg-Konfiguration zum Debuggen mithilfe von gdbserver konfigurieren. Weitere Details und ein Beispiel für eine Startkonfiguration finden Sie im Blogbeitrag Debuggen von Linux-CMake-Projekten mithilfe vongdbserver des Microsoft C++-Teams.

Weitere Informationen

CMake-Projekte in Visual Studio
Konfigurieren Sie ein Linux-CMake-Projekt
Verbinden Sie mit Ihrem Remotecomputer
Anpassen der CMake-Erstellungseinstellungen
Debugsitzungen von CMake konfigurieren
Bereitstellen, ausführen und debuggen Sie Ihr Linux-Projekt
CMake vordefinierter Konfigurationsverweis