cv2pdb converts DMD and DWARF debug information into PDB files for Visual Studio

Why D programs need a conversion step at all

cv2pdb is a converter of DMD CodeView and DWARF debug information to PDB files, and the README states the goal plainly: to make debugging of D applications that were created with the Digital Mars DMD compiler as painless as possible in current versions of Visual Studio, naming Visual Studio 2008 and VCExpress as the targets. The reason a converter is needed is a mismatch between two toolchains. DMD on Windows emits CodeView or DWARF debug records, and the Visual Studio debugger wants a PDB, which is a different container with its own type stream and symbol tables. The README also notes a side effect: other applications might benefit from the converted debug information too, naming WinDbg and DMC specifically. So the tool is not a debugger and does not attach to a process. It reads a built executable, produces a PDB file, and optionally rewrites the executable so the debugger is pointed at the new file. That separation matters for the workflow, because the conversion is a build step you can run once per binary rather than something that has to run while you debug.

The feature list and what each item buys you

The README enumerates the capabilities, and reading them in order shows what a D programmer is missing without this tool. Conversion of DMD CodeView information to a PDB file is the core, and conversion of DWARF information to a PDB file covers the alternate debug format DMD can emit. The converted line number info allows setting breakpoints, which is the basic capability a debugger user expects. Then comes the part that is genuinely D specific: display of variables, fields and objects in watch, local and auto window and in data tooltips. The tool generates generic debug info for dynamic arrays, associative arrays and delegates, which are the three container and function types where the Visual Studio debugger has no native representation, and an autoexp.dat allows convenient display of dynamic and associative arrays in watch windows. The README also lists demangles function names for convenient display of callstack, and notes that the tool also works when debugging executables built with the Digital Mars C/C++ compiler DMC. The demangling and the autoexp.dat are what make a D stack trace and a D array legible rather than a wall of mangled symbols.

Running the converter and launching the debugger

The quick start is one command on your executable. The README shows the following.

    cv2pdb debuggee.exe

Then you start the debugger on the converted executable, and the README gives two examples.

    devenv debuggee.exe

    vcexpress debuggee.exe

cv2pdb.exe is a command line tool which outputs its usage information if run without arguments, and that usage line is the complete option surface.

    usage: cv2pdb [-D<version>|-C|-n|-e|-s<C>|-p<embedded-pdb>|-l<debug-link>] <exe-file> [new-exe-file] [pdb-file]

Reading the syntax is the fastest way to understand the tool. The first file name is the executable or dynamic library compiled by the DMD compiler and containing the CodeView debug information, which means you must have built it with the -g option. The second file name is an optional new executable, and the third is an optional PDB file name. The -e option appears in the usage line without any further explanation in the README, which is one of the places the documentation stops short.

The DMD version problem and the -D option

One option carries more weight than the rest, and the README explains why at length. With the -D option you can specify the version of the DMD compiler you are using, and the problem is that this information is not embedded into the debug information, so the default is -D2.072. The README says that so far this information is only needed to determine whether char[] or const char[] is translated to string. Then the language implementation history enters the picture: starting with DMD 2.043, associative arrays have a slightly different implementation, so debug information needs to be adjusted as well, and this changed again with DMD 2.068. Version 2.072 started embedding source language D into object files, and the README says to use -D 2.043 or higher to produce the matching debug info. The practical consequence is that cv2pdb is version sensitive in a way most converters are not, and the version information has to be given by hand at conversion time. If you build with a DMD newer than 2.072 and leave the default in place, the const char[] versus char[] distinction can be wrong in the debugger, and the symptom is a type displayed incorrectly rather than an error.

Output files, the separate debug file and the -l option

By default, a PDB file is created with the same base name as the executable but with the extension pdb, and the executable is modified to redirect debuggers to this pdb-file instead of the original debug information. That in-place modification is convenient but it has a downside in a make-like build, and the README explains it: it is often useful to create a new file instead of modifying existing files, because then the file modification time can be used to continue the build process at the correct step. The alternative invocation writes the new executable to the second file name and leaves the input executable unmodified, and the pdb-file naming follows the base name of the output file.

    cv2pdb debuggee.exe debuggee_pdb.exe

The PDB file can also be renamed by specifying a third file name.

    cv2pdb debuggee.exe debuggee_pdb.exe debug.pdb

When the debug information lives in a separate file, the -l option specifies a link to that file, and the README adds that if the image has the .gnu_debuglink section the link is retrieved from the section and the -l option is not required. The debug information file is loaded from the same directory where the image file is located, and if there is no file there it is loaded from a .debug subdirectory.

    cv2pdb -ldebuggee.debug debuggee.exe

There is also the -p option, which replaces the absolute path of the PDB file with any other file name irrespective of the actually generated PDB file and without making the file reference absolute, which the README recommends when you plan to move the executable and PDB file to another computer.

The other switches and the C/C++ compiler path

Three more options are documented. The -C option tells the program that you want to debug a program compiled with DMC, the Digital Mars C/C++ compiler, and it will disable some of the D specific functions and enable adjustment of stack variable names. The -n option disables demangling of symbols, which is useful if you want raw symbol names. The -s option relates to a long-standing Visual Studio debugger limitation: older versions of the Visual Studio Debugger, up to VS 2012, don't work well if type and symbol names contain a dot, which is why cv2pdb replaces these characters with @ by default, and the -s option lets you configure another character, so -s. will keep symbol names as emitted by the compiler. These two defaults are a good example of a converter making a compromise for the debugger's benefit, and knowing about them saves a confusing afternoon when a D identifier arrives at the debugger mangled beyond recognition.

Building it, the licence file and where cv2pdb is the wrong tool

Installation is manual and the README is upfront about it: there is no full featured installer available yet, and you have to do some simple manual steps, with details in the file INSTALL. The Makefile in the repository shows what the build expects, and it is written for NMAKE. The prerequisites are that the environment variable VSINSTALLDIR must point to your Visual Studio or VCExpress installation folder, and that Info-zip must be found in the PATH, and the makefile is used to create source and binary packages with names cv2pdb_src_<VERSION>.zip and cv2pdb_<VERSION>.zip in the downloads directory. The source list names the files that matter to the design: cv2pdb.cpp, demangle.cpp, dwarf2pdb.cpp, mscvpdb.h, mspdb.cpp and PEImage.cpp. The licence situation is layered and worth reading before you redistribute anything. The code is distributed under the Artistic License 2.0. The file demangle.cpp is an adaption of denangle.d to C++ distributed with the DMD compiler and is placed into the Public Domain. The file mscvpdb.h is taken from the WINE project and the file dwarf.h from the libdwarf project, both under the GNU Lesser General Public License, version 2.1 or later. Where cv2pdb is the wrong tool is straightforward. If your debug information is already a PDB, there is nothing to convert. If you build with LDC or GDC rather than DMD, the -D version semantics described here do not apply. If your target is a non-Windows debugger, a PDB is not the format you want. And if you need DWARF to PDB conversion for C or C++ code produced by GCC or Clang, this is a D oriented tool whose DMC support exists as an aside. The project is written in C++ and its release history is slow, v0.54 in August 2025, v0.53 in December 2024 and v0.52 in March 2023, with the last push to the repository on 2026-10-15, so the code is current while the packaged releases are not.

Editorial conclusion

Adopt cv2pdb if you build D programs with the DMD compiler on Windows and you want to debug them in Visual Studio rather than in a D specific debugger, because the converter handles the CodeView to PDB translation and the D type quirks that the Visual Studio debugger does not understand on its own. Do not adopt it if your debug information already comes in a format the debugger reads natively, or if you are on a platform where the DMD toolchain is not the one producing your binaries. Verify two things before you rely on it: which DMD version compiled the executable, since the README says the version is not embedded in the debug information and defaults to 2.072, and whether your executable keeps debug information in a separate file, since the -l option and the .gnu_debuglink section decide where the converter looks for it. The practical first step is to run cv2pdb on a test executable with no arguments to see the usage line, then convert it with the default output name and open the result in the debugger.

Frequently asked questions

Official sources

1. Issues
2. License: Artistic-2.0
3. rainers/cv2pdb on GitHub
4. README
5. Releases