I've been in your shoes before—switching from Visual Studio to VSCode for C++ debugging can feel a bit tricky at first, but once you get the configs right, it's smooth sailing. Let's break down exactly what you need to set up to get your DLL client debugging with full PDB and source support.

Step 1: Set Up tasks.json for Compiling the Client #

First, you need to tell VSCode how to compile your client code, including where to find the DLL's header files and how to link against its import library. Here's a ready-to-adapt tasks.json file:

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "cppbuild",
            "label": "C/C++: g++.exe build active file",
            "command": "C:\\MinGW\\bin\\g++.exe",
            "args": [
                "-g", // Generates debug info critical for linking with PDB later
                "${file}",
                "-o",
                "${workspaceRoot}/dllclient.out",
                "-I", "path/to/your/header/files", // Replace with your actual header directory
                "-L", "path/to/your/dll/library", // Replace with directory containing your .lib/.a import library
                "-lmydll" // Replace with your DLL's import lib name (omit .lib/.a extension)
            ],
            "options": {
                "cwd": "${fileDirname}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "detail": "Task generated by Debugger."
        }
    ]
}

• The -g flag is non-negotiable—it ensures your executable includes debug metadata that gdb needs to connect to the PDB.
• For -lmydll: If your import library is mydll.lib (from Visual Studio) or libmydll.a (MinGW), g++ will automatically resolve the correct file when you use this flag.

Step 2: Update launch.json for Debugging with PDB & DLL #

Your existing launch.json needs a few key tweaks to help gdb locate the DLL, load PDB symbols, and map to the DLL's source code. Here's the updated configuration:

{
    "configurations": [
        {
            "name": "(gdb) DLL Client",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceRoot}/dllclient.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            // Add DLL directory to PATH so Windows can find it at runtime
            "environment": [
                {
                    "name": "PATH",
                    "value": "${workspaceRoot}/path/to/your/dll;${env:PATH}"
                }
            ],
            "externalConsole": false,
            "MIMode": "gdb",
            "miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
            "setupCommands": [
                {
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                },
                // Optional: Specify PDB directory if it's not alongside DLL/executable
                {
                    "text": "directory path/to/your/pdb/file",
                    "ignoreFailures": true
                }
            ],
            // Map DLL's build-time source paths to your local source directory
            "sourceFileMap": {
                "/original/build/path/of/dll/src": "${workspaceRoot}/path/to/your/local/dll/source"
            },
            // Explicitly tell gdb where to look for PDB symbols
            "symbolSearchPath": "${workspaceRoot}/path/to/your/pdb"
        }
    ]
}

Let's break down the critical additions:

• environment: This adds your DLL's directory to the system PATH, so Windows can locate the DLL when launching your client. Replace the path with where your mydll.dll is stored.
• symbolSearchPath: Ensures gdb knows where to find the PDB file. If your PDB is in the same folder as the DLL or executable, this might be optional, but it's always safe to set explicitly.
• sourceFileMap: If the DLL was built with absolute source paths that don't match your local setup (e.g., the DLL was built on another machine), this maps those old paths to your current source directory. This is essential for gdb to jump to the DLL's source code when debugging.
• setupCommands: The optional directory command gives gdb an extra hint about where to find source files if it can't resolve them automatically.

Additional Tips for Smooth Debugging #

• Check Symbol Loading: When you start a debug session, keep an eye on the VSCode Debug Console. Look for lines like Reading symbols from path/to/mydll.pdb...—this confirms gdb is loading the PDB correctly.
• Auto-Copy DLL/PDB: To replicate Visual Studio's post-build copy behavior, add a shell task to tasks.json that copies the DLL and PDB to your client's directory. Add a dependsOn rule to run it automatically after building:

  {
      "label": "Copy DLL & PDB",
      "type": "shell",
      "command": "xcopy /Y \"path/to/your/mydll.dll\" \"${workspaceRoot}\" && xcopy /Y \"path/to/your/mydll.pdb\" \"${workspaceRoot}\"",
      "dependsOn": ["C/C++: g++.exe build active file"]
  }
  

• PDB Compatibility Note: If your DLL was built with Visual Studio, MinGW's gdb might have limited support for its PDB format. If you hit symbol-loading issues, try rebuilding the DLL with MinGW (using your existing Makefile) to generate a gdb-compatible debug file.

内容的提问来源于stack exchange，提问作者rockstiff