ist jetzt verfügbar! Lesen Sie über die neuen Funktionen und Fehlerbehebungen vom November.

C/C++ Debugging konfigurieren

Eine launch.json-Datei wird verwendet, um den Debugger in Visual Studio Code zu konfigurieren.

Visual Studio Code generiert eine launch.json (unter einem .vscode-Ordner in Ihrem Projekt) mit fast allen erforderlichen Informationen. Um mit dem Debugging zu beginnen, müssen Sie das Feld program mit dem Pfad zur ausführbaren Datei, die Sie debuggen möchten, ausfüllen. Dies muss sowohl für die Start- als auch für die Anhangskonfigurationen (falls Sie sich zu einem bestimmten Zeitpunkt an eine laufende Instanz anhängen möchten) angegeben werden.

Die generierte Datei enthält zwei Abschnitte: einen, der das Debugging für den Start konfiguriert, und einen zweiten, der das Debugging für den Anhang konfiguriert.

Konfigurieren Sie das Debugging-Verhalten von VS Code

Legen Sie die folgenden Optionen fest oder ändern Sie sie, um das Verhalten von VS Code während des Debuggings zu steuern.

program (erforderlich)

Gibt den vollständigen Pfad zur ausführbaren Datei an, die der Debugger startet oder an die er sich anhängt. Der Debugger benötigt diesen Speicherort, um Debug-Symbole zu laden.

symbolSearchPath

Teilt dem Visual Studio Windows Debugger mit, in welchen Pfaden nach Symbol (.pdb)-Dateien gesucht werden soll. Trennen Sie mehrere Pfade mit einem Semikolon. Beispiel: "C:\\Symbole;C:\\SymbolVerz2".

requireExactSource

Ein optionales Flag, das dem Visual Studio Windows Debugger mitteilt, dass der aktuelle Quellcode mit der PDB-Datei übereinstimmen muss.

additionalSOLibSearchPath

Teilt GDB oder LLDB mit, in welchen Pfaden nach .so-Dateien gesucht werden soll. Trennen Sie mehrere Pfade mit einem Semikolon. Beispiel: "/Users/user/dir1;/Users/user/dir2".

externalConsole

Wird nur beim Starten des Debug-Ziels verwendet. Für attach ändert dieser Parameter das Verhalten des Debug-Ziels nicht.

  • Windows: Wenn auf true gesetzt, wird eine externe Konsole gestartet. Wenn auf false gesetzt, wird das integrierte Terminal von VS Code verwendet.
  • Linux: Wenn auf true gesetzt, wird VS Code benachrichtigt, eine externe Konsole zu starten. Wenn auf false gesetzt, wird das integrierte Terminal von VS Code verwendet.
  • macOS: Wenn auf true gesetzt, wird eine externe Konsole über lldb-mi gestartet. Wenn auf false gesetzt, kann die Ausgabe in der Debug-Konsole von VS Code angezeigt werden. Aufgrund von Einschränkungen in lldb-mi ist die Unterstützung für integrierte Terminals nicht verfügbar.

avoidWindowsConsoleRedirection

Um das integrierte Terminal von VS Code mit gdb unter Windows zu unterstützen, fügt die Erweiterung Konsolenumleitungsbefehle zu den Argumenten des Debug-Ziels hinzu, damit die Konsolenein- und -ausgabe im integrierten Terminal angezeigt wird. Das Setzen dieser Option auf true deaktiviert dies.

logging

Optionale Flags, um zu bestimmen, welche Arten von Meldungen in der Debug-Konsole protokolliert werden sollen.

  • exceptions: Optionales Flag, um zu bestimmen, ob Ausnahmemeldungen in der Debug-Konsole protokolliert werden sollen. Standard ist true.
  • moduleLoad: Optionales Flag, um zu bestimmen, ob Modulladeereignisse in der Debug-Konsole protokolliert werden sollen. Standard ist true.
  • programOutput: Optionales Flag, um zu bestimmen, ob Programmausgaben in der Debug-Konsole protokolliert werden sollen. Standard ist true.
  • engineLogging: Optionales Flag, um zu bestimmen, ob diagnostische Engine-Protokolle in der Debug-Konsole protokolliert werden sollen. Standard ist false.
  • trace: Optionales Flag, um zu bestimmen, ob diagnostische Adapterbefehlsverfolgung in der Debug-Konsole protokolliert werden soll. Standard ist false.
  • traceResponse: Optionales Flag, um zu bestimmen, ob diagnostische Adapterbefehls- und Antwortverfolgung in der Debug-Konsole protokolliert werden sollen. Standard ist false.

visualizerFile

.natvis-Datei, die beim Debugging verwendet werden soll. Siehe Benutzerdefinierte Ansichten nativer Objekte erstellen für Informationen zur Erstellung von Natvis-Dateien.

showDisplayString

Wenn eine visualizerFile angegeben ist, aktiviert showDisplayString die Anzeigestrecke. Das Aktivieren dieser Option kann während des Debuggings zu einer Verlangsamung führen.

Beispiel

{
  "name": "C++ Launch (Windows)",
  "type": "cppvsdbg",
  "request": "launch",
  "program": "C:\\app1\\Debug\\app1.exe",
  "symbolSearchPath": "C:\\Symbols;C:\\SymbolDir2",
  "externalConsole": true,
  "logging": {
    "moduleLoad": false,
    "trace": true
  },
  "visualizerFile": "${workspaceFolder}/my.natvis",
  "showDisplayString": true
}

Zielanwendung konfigurieren

Die folgenden Optionen ermöglichen es Ihnen, den Zustand der Zielanwendung beim Start zu ändern.

args

JSON-Array von Befehlszeilenargumenten, die beim Start an das Programm übergeben werden sollen. Beispiel ["arg1", "arg2"]. Wenn Sie Zeichen maskieren, müssen Sie sie doppelt maskieren. Zum Beispiel sendet ["{\\\"arg1\\\": true}"] {"arg1": true} an Ihre Anwendung.

cwd

Legt das Arbeitsverzeichnis der vom Debugger gestarteten Anwendung fest.

environment

Umgebungsvariablen, die zur Umgebung für das Programm hinzugefügt werden sollen. Beispiel: [ { "name": "config", "value": "Debug" } ], nicht [ { "config": "Debug" } ].

Beispiel

{
  "name": "C++ Launch",
  "type": "cppdbg",
  "request": "launch",
  "program": "${workspaceFolder}/a.out",
  "args": ["arg1", "arg2"],
  "environment": [{ "name": "config", "value": "Debug" }],
  "cwd": "${workspaceFolder}"
}

GDB oder LLDB anpassen

Sie können das Verhalten von GDB oder LLDB ändern, indem Sie die folgenden Optionen festlegen.

MIMode

Gibt den Debugger an, mit dem VS Code eine Verbindung herstellen wird. Muss auf gdb oder lldb gesetzt sein. Dies ist pro Betriebssystem vorkonfiguriert und kann bei Bedarf geändert werden.

miDebuggerPath

Der Pfad zum Debugger (z. B. gdb). Wenn nur die ausführbare Datei angegeben ist, wird auf der PATH-Variable des Betriebssystems nach einem Debugger gesucht (GDB unter Linux und Windows, LLDB unter OS X).

miDebuggerArgs

Zusätzliche Argumente, die an den Debugger (z. B. gdb) übergeben werden sollen.

stopAtEntry

Wenn auf true gesetzt, sollte der Debugger am Einstiegspunkt des Ziels stoppen (wird beim Anhängen ignoriert). Der Standardwert ist false.

stopAtConnect

Wenn auf true gesetzt, stoppt der Debugger nach der Verbindung mit dem Ziel. Wenn auf false gesetzt, fährt der Debugger nach der Verbindung fort. Der Standardwert ist false.

setupCommands

JSON-Array von Befehlen, die ausgeführt werden sollen, um GDB oder LLDB einzurichten. Beispiel: "setupCommands": [ { "text": "target-run", "description": "run target", "ignoreFailures": false }].

customLaunchSetupCommands

Wenn angegeben, ersetzt dies die Standardbefehle zum Starten eines Ziels durch andere Befehle. Dies kann beispielsweise "-target-attach" sein, um sich an einen Zielprozess anzuhängen. Eine leere Befehlsliste ersetzt die Startbefehle durch nichts, was nützlich sein kann, wenn dem Debugger Startoptionen als Befehlszeilenoptionen übergeben werden. Beispiel: "customLaunchSetupCommands": [ { "text": "target-run", "description": "run target", "ignoreFailures": false }].

launchCompleteCommand

Der Befehl, der ausgeführt werden soll, nachdem der Debugger vollständig eingerichtet ist, um den Zielprozess zum Laufen zu bringen. Zulässige Werte sind "exec-run", "exec-continue", "None". Der Standardwert ist "exec-run".

Beispiel

{
  "name": "C++ Launch",
  "type": "cppdbg",
  "request": "launch",
  "program": "${workspaceFolder}/a.out",
  "stopAtEntry": false,
  "customLaunchSetupCommands": [
    { "text": "target-run", "description": "run target", "ignoreFailures": false }
  ],
  "launchCompleteCommand": "exec-run",
  "linux": {
    "MIMode": "gdb",
    "miDebuggerPath": "/usr/bin/gdb"
  },
  "osx": {
    "MIMode": "lldb"
  },
  "windows": {
    "MIMode": "gdb",
    "miDebuggerPath": "C:\\MinGw\\bin\\gdb.exe"
  }
}

symbolLoadInfo

  • loadAll: Wenn true, werden Symbole für alle Libs geladen, andernfalls werden keine Solib-Symbole geladen. Modifiziert durch ExceptionList. Der Standardwert ist true.
  • exceptionList: Liste von Dateinamen (Wildcards erlaubt), getrennt durch Semikolons ;. Modifiziert das Verhalten von LoadAll. Wenn LoadAll true ist, werden keine Symbole für Libs geladen, die einem Namen in der Liste entsprechen. Andernfalls werden nur Symbole für Libs geladen, die übereinstimmen. Beispiel: "foo.so;bar.so"

Dump-Dateien debuggen

Die C/C++-Erweiterung ermöglicht das Debuggen von Dump-Dateien unter Windows und Core-Dump-Dateien unter Linux und OS X.

dumpPath

Wenn Sie eine Windows-Dumpdatei debuggen möchten, setzen Sie dies auf den Pfad zur Dumpdatei, um das Debugging in der launch-Konfiguration zu starten.

coreDumpPath

Vollständiger Pfad zu einer Core-Dump-Datei, die für das angegebene Programm debuggt werden soll. Setzen Sie dies auf den Pfad zur Core-Dump-Datei, um das Debugging in der launch-Konfiguration zu starten. Hinweis: Das Debugging von Core-Dumps wird mit MinGw nicht unterstützt.

Remote-Debugging oder Debugging mit einem lokalen Debugger-Server

miDebuggerServerAddress

Netzwerkadresse des Debugger-Servers (z. B. gdbserver), mit dem für Remote-Debugging eine Verbindung hergestellt werden soll (Beispiel: localhost:1234).

debugServerPath

Vollständiger Pfad zum zu startenden Debug-Server.

debugServerArgs

Argumente für den Debugger-Server.

serverStarted

Muster für "Server gestartet", nach dem in der Ausgabe des Debug-Servers gesucht werden soll. Reguläre Ausdrücke werden unterstützt.

filterStdout

Wenn auf true gesetzt, wird der stdout-Stream nach dem Muster "Server gestartet" durchsucht und stdout wird an die Debug-Ausgabe protokolliert. Der Standardwert ist true.

filterStderr

Wenn auf true gesetzt, wird der stderr-Stream nach dem Muster "Server gestartet" durchsucht und stderr wird an die Debug-Ausgabe protokolliert. Der Standardwert ist false.

serverLaunchTimeout

Zeit in Millisekunden, die der Debugger auf den Start des DebugServers wartet. Standard ist 10000.

pipeTransport

Informationen zum Anhängen an einen Remote-Prozess, z. B. zum Debuggen eines Prozesses in einem Docker-Container, finden Sie im Artikel Pipe-Transport-Einstellungen.

hardwareBreakpoints

Wenn angegeben, steuert dies explizit das Verhalten von Hardware-Breakpoints für Remote-Ziele. Wenn require auf true gesetzt ist, werden immer Hardware-Breakpoints verwendet. Der Standardwert ist false. limit ist eine optionale Beschränkung der Anzahl der verfügbaren Hardware-Breakpoints, die verwendet werden können. Dies wird nur erzwungen, wenn require auf true und limit größer als 0 gesetzt ist. Der Standardwert ist 0. Beispiel: "hardwareBreakpoints": { require: true, limit: 6 }.

Zusätzliche Eigenschaften

processId

Standardmäßig ${command:pickProcess}, was eine Liste der verfügbaren Prozesse anzeigt, an die sich der Debugger anhängen kann. Wir empfehlen, diesen Standard beizubehalten, aber die Eigenschaft kann explizit auf eine bestimmte Prozess-ID gesetzt werden, an die sich der Debugger anhängen soll.

request

Gibt an, ob der Konfigurationsabschnitt dazu bestimmt ist, das Programm zu starten (launch) oder sich an eine bereits laufende Instanz anzuhängen (attach).

targetArchitecture

Veraltet Diese Option ist nicht mehr erforderlich, da die Zielarchitektur automatisch erkannt wird.

type

Gibt den zugrunde liegenden Debugger an, der verwendet wird. Muss cppvsdbg sein, wenn der Visual Studio Windows Debugger verwendet wird, und cppdbg, wenn GDB oder LLDB verwendet wird. Dies wird automatisch auf den richtigen Wert gesetzt, wenn die launch.json-Datei erstellt wird.

sourceFileMap

Dies ermöglicht die Abbildung von Compile-Zeit-Pfaden für Quellcode auf lokale Quellcode-Speicherorte. Es handelt sich um ein Objekt mit Schlüssel-Wert-Paaren und löst den ersten Pfad auf, der mit einer Zeichenfolge übereinstimmt. (Beispiel: "sourceFileMap": { "/mnt/c": "c:\\" } ordnet jeden Pfad, der vom Debugger zurückgegeben wird und mit /mnt/c beginnt, in c:\\ um. Sie können mehrere Zuordnungen im Objekt haben, diese werden jedoch in der angegebenen Reihenfolge verarbeitet.)

Datei mit Umgebungsvariablendefinitionen

Eine Datei mit Umgebungsvariablendefinitionen ist eine einfache Textdatei, die Schlüssel-Wert-Paare im Format umgebungsvariable=wert enthält, wobei # für Kommentare verwendet wird. Mehrzeilige Werte werden nicht unterstützt.

Die cppvsdbg-Debuggerkonfiguration enthält auch eine Eigenschaft envFile, mit der Sie Variablen zu Debugging-Zwecken einfach festlegen können.

Zum Beispiel

projekt.env-Datei:

# project.env

# Example environment with key as 'MYENVRIONMENTPATH' and value as C:\\Users\\USERNAME\\Project
MYENVRIONMENTPATH=C:\\Users\\USERNAME\\Project

# Variables with spaces
SPACED_OUT_PATH="C:\\This Has Spaces\\Project"

Symboloptionen

Das Element symbolOptions ermöglicht die Anpassung, wie der Debugger nach Symbolen sucht. Beispiel

    "symbolOptions": {
        "searchPaths": [
            "C:\\src\\MyOtherProject\\bin\\debug",
            "https://my-companies-symbols-server"
        ],
        "searchMicrosoftSymbolServer": true,
        "cachePath": "%TEMP%\\symcache",
        "moduleFilter": {
            "mode": "loadAllButExcluded",
            "excludedModules": [ "DoNotLookForThisOne*.dll" ]
        }
    }

Eigenschaften

searchPaths: Array von Symbolserver-URLs (Beispiel: https://msdl.microsoft.com/download/symbols) oder Verzeichnissen (Beispiel: /build/symbols) nach .pdb-Dateien. Diese Verzeichnisse werden zusätzlich zu den Standardorten durchsucht - neben dem Modul und dem Pfad, zu dem die PDB ursprünglich abgelegt wurde.

searchMicrosoftSymbolServer: Wenn true, wird der Microsoft Symbol Server (https://msdl.microsoft.com/download/symbols) zum Suchpfad für Symbole hinzugefügt. Wenn nicht angegeben, ist diese Option standardmäßig false.

cachePath: Verzeichnis, in dem Symbole von Symbolservern heruntergeladen werden sollen. Wenn nicht angegeben, wählt der Debugger standardmäßig %TEMP%\SymbolCache..

moduleFilter.mode: Dieser Wert ist entweder "loadAllButExcluded" oder "loadOnlyIncluded". Im Modus "loadAllButExcluded" lädt der Debugger Symbole für alle Module, es sei denn, das Modul befindet sich im Array 'excludedModules'. Im Modus "loadOnlyIncluded" versucht der Debugger nicht, Symbole für IRGENDEIN Modul zu laden, es sei denn, es befindet sich im Array 'includedModules' oder es wird über die Einstellung 'includeSymbolsNextToModules' einbezogen.

Eigenschaften für den Modus "loadAllButExcluded"

moduleFilter.excludedModules: Array von Modulen, für die der Debugger KEINE Symbole laden soll. Wildcards (Beispiel: MyCompany.*.dll) sind unterstützt.

Eigenschaften für den Modus "loadOnlyIncluded"

moduleFilter.includedModules: Array von Modulen, für die der Debugger Symbole laden soll. Wildcards (Beispiel: MyCompany.*.dll) sind unterstützt.

moduleFilter.includeSymbolsNextToModules: Wenn true, prüft der Debugger für jedes Modul, das NICHT im Array 'includedModules' enthalten ist, weiterhin neben dem Modul selbst und der gestarteten ausführbaren Datei, prüft aber keine Pfade in der Symbolsuchliste. Diese Option ist standardmäßig auf 'true' gesetzt.

6/10/2021
© . This site is unofficial and not affiliated with Microsoft.