Entdecken Sie agentenbasierte Entwicklung –

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 im Feld program den Pfad zu der ausführbaren Datei angeben, die Sie debuggen möchten. Dies muss sowohl für die Launch- als auch für die Attach-Konfiguration (falls Sie zu irgendeinem Zeitpunkt an eine laufende Instanz anhängen möchten) angegeben werden.

Die generierte Datei enthält zwei Abschnitte: einen zur Konfiguration des Debuggings für den Start (Launch) und einen zweiten zur Konfiguration des Debuggings für das Anhängen (Attach).

Debugging-Verhalten von VS Code konfigurieren

Legen Sie die folgenden Optionen fest oder ändern Sie diese, um das Verhalten von VS Code während des Debuggens 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-Dateien (.pdb) gesucht werden soll. Trennen Sie mehrere Pfade durch ein Semikolon. Zum Beispiel: "C:\\Symbols;C:\\SymbolDir2".

requireExactSource

Ein optionales Flag, das den Visual Studio Windows Debugger anweist, zu fordern, dass der aktuelle Quellcode mit der PDB-Datei übereinstimmt.

additionalSOLibSearchPath

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

externalConsole

Wird nur beim Starten des zu debuggenden Programms verwendet. Für attach ändert dieser Parameter das Verhalten des zu debuggenden Programms nicht.

  • Windows: Wenn auf true gesetzt, wird eine externe Konsole gestartet. Wenn auf false gesetzt, wird das integratedTerminal von VS Code verwendet.
  • Linux: Wenn auf true gesetzt, wird VS Code benachrichtigt, eine externe Konsole zu starten. Wenn auf false gesetzt, wird das integratedTerminal 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 eingesehen werden. Aufgrund von Einschränkungen innerhalb von lldb-mi ist die Unterstützung für das integrierte Terminal 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 zu debuggenden Programms hinzu, damit Konsolenein- und -ausgaben im integrierten Terminal angezeigt werden. Wenn Sie diese Option auf true setzen, wird dies deaktiviert.

logging

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

  • exceptions: Optionales Flag, um zu bestimmen, ob Ausnahmemeldungen in der Debug-Konsole protokolliert werden sollen. Standardwert ist true.
  • moduleLoad: Optionales Flag, um zu bestimmen, ob Modulladeereignisse in der Debug-Konsole protokolliert werden sollen. Standardwert ist true.
  • programOutput: Optionales Flag, um zu bestimmen, ob die Programmausgabe in der Debug-Konsole protokolliert werden soll. Standardwert ist true.
  • engineLogging: Optionales Flag, um zu bestimmen, ob diagnostische Engine-Logs in der Debug-Konsole protokolliert werden sollen. Standardwert ist false.
  • trace: Optionales Flag, um zu bestimmen, ob die Ablaufverfolgung der Adapterbefehle in der Debug-Konsole protokolliert werden soll. Standardwert ist false.
  • traceResponse: Optionales Flag, um zu bestimmen, ob die Ablaufverfolgung der Befehle und Antworten des Adapters in der Debug-Konsole protokolliert werden sollen. Standardwert ist false.

visualizerFile

Die beim Debuggen zu verwendende .natvis-Datei. Informationen zum Erstellen von Natvis-Dateien finden Sie unter Erstellen benutzerdefinierter Ansichten für native Objekte.

showDisplayString

Wenn eine visualizerFile angegeben ist, aktiviert showDisplayString die Anzeigezeichenfolge (Display String). Das Aktivieren dieser Option kann das Debugging verlangsamen.

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 Status der Zielanwendung beim Start zu ändern

args

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

cwd

Legt das Arbeitsverzeichnis der vom Debugger gestarteten Anwendung fest.

environment

Umgebungsvariablen, die der Umgebung des Programms 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 sich VS Code verbinden wird. Muss auf gdb oder lldb eingestellt sein. Dies ist betriebssystemabhängig vorkonfiguriert und kann bei Bedarf geändert werden.

miDebuggerPath

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

miDebuggerArgs

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

stopAtEntry

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

stopAtConnect

Wenn auf true gesetzt, sollte der Debugger nach der Verbindung mit dem Ziel anhalten. Wenn auf false gesetzt, wird der Debugger nach der Verbindung fortgesetzt. 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

Falls angegeben, ersetzt dies die Standardbefehle zum Starten eines Ziels durch andere Befehle. Dies kann zum Beispiel "-target-attach" sein, um 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 nach der vollständigen Einrichtung des Debuggers ausgeführt werden soll, um den Zielprozess zu starten. 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 Bibliotheken geladen, andernfalls werden keine Symbole für gemeinsam genutzte Bibliotheken (solib) geladen. Wird durch ExceptionList modifiziert. Standardwert ist true.
  • exceptionList: Liste von Dateinamen (Platzhalter erlaubt), getrennt durch Semikolons ;. Ändert das Verhalten von LoadAll. Wenn LoadAll true ist, werden keine Symbole für Bibliotheken geladen, die einem Namen in der Liste entsprechen. Andernfalls werden nur Symbole für Bibliotheken 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-Dump-Datei debuggen möchten, legen Sie dies in der launch-Konfiguration auf den Pfad zur Dump-Datei fest, um das Debugging zu starten.

coreDumpPath

Vollständiger Pfad zu einer Core-Dump-Datei, die für das angegebene Programm debuggt werden soll. Legen Sie dies in der launch-Konfiguration auf den Pfad zur Core-Dump-Datei fest, um das Debugging zu starten. Hinweis: Das Debuggen 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), zu dem für das 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 den Serverstart, 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 Serverstartmuster durchsucht und die Standardausgabe in der Debug-Ausgabe protokolliert. Standardwert ist true.

filterStderr

Wenn auf true gesetzt, wird der stderr-Stream nach dem Serverstartmuster durchsucht und die Standardfehlerausgabe in der Debug-Ausgabe protokolliert. Standardwert ist false.

serverLaunchTimeout

Zeit in Millisekunden, die der Debugger auf den Start des debugServer warten soll. Standardwert ist 10000.

pipeTransport

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

hardwareBreakpoints

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

Zusätzliche Eigenschaften

processId

Standardmäßig ${command:pickProcess}, wodurch eine Liste der verfügbaren Prozesse angezeigt wird, an die der Debugger angehängt werden kann. Wir empfehlen, diese Standardeinstellung beizubehalten, aber die Eigenschaft kann explizit auf eine bestimmte Prozess-ID festgelegt werden, an die der Debugger angehängt werden soll.

request

Gibt an, ob der Konfigurationsabschnitt dazu vorgesehen ist, das Programm zu starten (launch) oder 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. Muss cppvsdbg bei Verwendung des Visual Studio Windows Debuggers und cppdbg bei Verwendung von GDB oder LLDB sein. Dies wird beim Erstellen der launch.json-Datei automatisch auf den korrekten Wert gesetzt.

sourceFileMap

Dies ermöglicht die Zuordnung der Pfade zur Kompilierzeit zum Quellcode zu lokalen Quellpfaden. Es handelt sich um ein Objekt mit Schlüssel-Wert-Paaren, das den ersten Pfad auflöst, der mit der 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, die jedoch in der angegebenen Reihenfolge verarbeitet werden.)

Datei mit Umgebungsvariablendefinitionen

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

Die Debugger-Konfiguration cppvsdbg enthält auch eine envFile-Eigenschaft, mit der Sie Variablen für Debugging-Zwecke einfach festlegen können.

Zum Beispiel

project.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"

Symbol-Optionen

Das symbolOptions-Element ermöglicht die Anpassung der Suche des Debuggers nach Symbolen. 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), in denen nach .pdb-Dateien gesucht werden soll. Diese Verzeichnisse werden zusätzlich zu den Standard-Speicherorten durchsucht – neben dem Modul und dem Pfad, an dem die PDB-Datei ursprünglich abgelegt wurde.

searchMicrosoftSymbolServer: Wenn true, wird der Microsoft-Symbolserver (https://msdl.microsoft.com/download/symbols) zum Suchpfad für Symbole hinzugefügt. Falls nicht spezifiziert, ist der Standardwert für diese Option false.

cachePath: Verzeichnis, in dem von Symbolservern heruntergeladene Symbole zwischengespeichert werden sollen. Falls nicht spezifiziert, verwendet 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 ist über die Einstellung 'includeSymbolsNextToModules' eingeschlossen.

Eigenschaften für den Modus "loadAllButExcluded"

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

Eigenschaften für den Modus "loadOnlyIncluded"

moduleFilter.includedModules: Array von Modulen, für die der Debugger Symbole laden soll. Platzhalter (Beispiel: MyCompany.*.dll) werden 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 startenden ausführbaren Datei, prüft jedoch keine Pfade in der Symbolsuchliste. Diese Option hat den Standardwert 'true'.

6/10/2021
© . This website operates independently and is not affiliated with or endorsed by Microsoft. All brand names, logos, and trademarks are the property of their respective owners.