PDB debug info

Hi people,

Unlike GCC, LLVM has seemingly good support for interoperability with MSVC built windows code.
This makes LLVM particularly attractive to my company/project, but it seems LLVM doesn’t support writing PDB debug into into it’s COFF output.

It seems Win64 exception handling has been added recently, which perhaps makes PDB the only outstanding feature for effective use with windows projects.

Can anyone comment on the state of this? Anyone interested or working on PDB support? Plans? Show stoppers?

Cheers.

  • Manu

Show stoppers?

Lack of any specification

This project seems to have some ability to convert to PDB, though it looks like the project stalled years ago…

http://www.dsource.org/projects/visuald

I have done some research into the area, and the visual studio compiler doesn’t look to embed debug info directly into the object file at all, instead a single program database for the project is updated incrementally as each source file is compiled.

I have on occasion got the inspiration to create a DWARF debug module for visual studio, then quickly go lost trying to get started. It looks like google has/is attempting to go down this road according to the pages:

http://www.chromium.org/nativeclient/sdk/vsx-plugin/vsx-reference-material
http://code.google.com/p/nativeclient/wiki/NaClDebugging

though a more recent page doesn’t mention visual studio:

https://developers.google.com/native-client/devguide/devcycle/debugging

Oops, I’ve managed to exclude the list…

This project seems to have some ability to convert to PDB, though it looks like the project stalled years ago…

http://www.dsource.org/projects/visuald

Years ago? Latest release was only 2 months ago.

My mistake, I was referring to cv2pdb which according the the web-page last had news in 2006. I had not looked in a few years. According to the repository, the project has not had a commit in three years.

He recently added DWARF support, and serviced a couple of feature requests for me, so it’s still alive. I’m sure he’d be happy to comment/help out.

I have seen mention somewhere that Microsoft’s link.exe is able to extract CodeView debug info from COFF objects while linking to produce the final PDB file… maybe there’s something potentially useful in there?

cv2pdb which I mentioned above builds PDB files from both CV and DWARF info contained in final binaries (PE files at least?).

Is it technically possible to put debug info in MS compatible COFF objects if it behaves as you say above? How would a linker then take it and produce a PDB file at link time? And does MS link.exe not do this its self?
Perhaps if link.exe does actually support CV in COFF, then it’s just a matter of writing CV to the objects, and using the MS linker to link and produce the PDB file?

Their are a couple of options available that allow you to embed debug info directly into an object file. The /Z7 (enable old-style debug info) option does not produce a separate PDB file, presumably this generates CodeView 7 information directly into the object file. The /Yd appears to embed addition information into the object file along with generating a program database, but it gives this warning when used “option ‘Yd’ has been deprecated and will be removed in a future release”

/Z7, that’s the one. Maybe this approach can be used by LLVM? I presume LLVM is capable of producing CV info already? Maybe this configuration is already possible?
It’d be interesting to try it out, CV in the COFF objects, and see if the linker makes sense of it at link time…

I have on occasion got the inspiration to create a DWARF debug module for visual studio, then quickly go lost trying to get started. It looks like google has/is attempting to go down this road according to the pages:

http://www.chromium.org/nativeclient/sdk/vsx-plugin/vsx-reference-material
http://code.google.com/p/nativeclient/wiki/NaClDebugging

though a more recent page doesn’t mention visual studio:

https://developers.google.com/native-client/devguide/devcycle/debugging

It’s an interesting approach, and I’d take it as a start, but it’s still basically a hack. Interoperability with MSVC is non-negotiable in many windows projects.
LLVM is perhaps the closest project to salvation, this is the only real limiting factor :confused:

I would not consider this a hack. For my own use, and I’m sure others would agree, I would prefer another tool chain. I just want the productivity enhancements I get from the Visual Studio IDE. Though I agree that their are projects where MS debug information is required, due to linking against legacy code that cannot for what ever reason me compiled with a different tool chain.

I’d also argue that the VS debugger is possibly the single biggest productivity enhancement offered by the IDE :wink:
And yeah, I’m in the situation where I need to link against MSVC built code, so I need PDB at the end of the day.

Your approach would be really handy in other cases though, DWARF plugin for VisualStudio would be a generally useful tool.

Oops, I’ve managed to exclude the list…

This project seems to have some ability to convert to PDB, though it looks like the project stalled years ago…

http://www.dsource.org/projects/visuald

Years ago? Latest release was only 2 months ago.

My mistake, I was referring to cv2pdb which according the the web-page last had news in 2006. I had not looked in a few years. According to the repository, the project has not had a commit in three years.

He recently added DWARF support, and serviced a couple of feature requests for me, so it’s still alive. I’m sure he’d be happy to comment/help out.

I have seen mention somewhere that Microsoft’s link.exe is able to extract CodeView debug info from COFF objects while linking to produce the final PDB file… maybe there’s something potentially useful in there?

cv2pdb which I mentioned above builds PDB files from both CV and DWARF info contained in final binaries (PE files at least?).

Is it technically possible to put debug info in MS compatible COFF objects if it behaves as you say above? How would a linker then take it and produce a PDB file at link time? And does MS link.exe not do this its self?
Perhaps if link.exe does actually support CV in COFF, then it’s just a matter of writing CV to the objects, and using the MS linker to link and produce the PDB file?

Their are a couple of options available that allow you to embed debug info directly into an object file. The /Z7 (enable old-style debug info) option does not produce a separate PDB file, presumably this generates CodeView 7 information directly into the object file. The /Yd appears to embed addition information into the object file along with generating a program database, but it gives this warning when used “option ‘Yd’ has been deprecated and will be removed in a future release”

/Z7, that’s the one. Maybe this approach can be used by LLVM? I presume LLVM is capable of producing CV info already? Maybe this configuration is already possible?
It’d be interesting to try it out, CV in the COFF objects, and see if the linker makes sense of it at link time…

I was able to get clang to produce COFF files with embedded DWARF debug relatively easily, which produces executables debuggable via the MinGW tool-chain. To support another debug format would be difficult I think, though I’m no expert on the subject. Currently LLVM internally represents everything more or less directly in DWARF. All of the debug meta-data attached to the IR is a slightly higher representation of DWARF data-structures. While there is a debug info builder class the insulates front ends from the details of DWARF to some extent, it is not complete isolation. I think the only feasible approach is to translate the DWARF info into CV info at a lower level, perhaps after the initial COFF object file containing DWARF has been emitted.

I have on occasion got the inspiration to create a DWARF debug module for visual studio, then quickly go lost trying to get started. It looks like google has/is attempting to go down this road according to the pages:

http://www.chromium.org/nativeclient/sdk/vsx-plugin/vsx-reference-material
http://code.google.com/p/nativeclient/wiki/NaClDebugging

though a more recent page doesn’t mention visual studio:

https://developers.google.com/native-client/devguide/devcycle/debugging

It’s an interesting approach, and I’d take it as a start, but it’s still basically a hack. Interoperability with MSVC is non-negotiable in many windows projects.
LLVM is perhaps the closest project to salvation, this is the only real limiting factor :confused:

I would not consider this a hack. For my own use, and I’m sure others would agree, I would prefer another tool chain. I just want the productivity enhancements I get from the Visual Studio IDE. Though I agree that their are projects where MS debug information is required, due to linking against legacy code that cannot for what ever reason me compiled with a different tool chain.

I’d also argue that the VS debugger is possibly the single biggest productivity enhancement offered by the IDE :wink:
And yeah, I’m in the situation where I need to link against MSVC built code, so I need PDB at the end of the day.

Your approach would be really handy in other cases though, DWARF plugin for VisualStudio would be a generally useful tool.

From what I was able to gather while looking into a debugger plugin, the existing user interface would drive all debuggers, thus the user should have more or less the same debugging experience with any fully implemented plugin.

/Z7, that’s the one. Maybe this approach can be used by LLVM? I presume LLVM is capable of producing CV info already? Maybe this configuration is already possible?
It’d be interesting to try it out, CV in the COFF objects, and see if the linker makes sense of it at link time…

I was able to get clang to produce COFF files with embedded DWARF debug relatively easily, which produces executables debuggable via the MinGW tool-chain.

This sounds effectively identical to what I have now using MinGW GCC to produce COFF binaries with DWARF debug info, and then running cv2pdb after linking to extract a PDB from the binary. It works, but it means I can’t link against MSVC libs/objects because of the conflicting debug info formats. :confused:

To support another debug format would be difficult I think, though I’m no expert on the subject. Currently LLVM internally represents everything more or less directly in DWARF. All of the debug meta-data attached to the IR is a slightly higher representation of DWARF data-structures. While there is a debug info builder class the insulates front ends from the details of DWARF to some extent, it is not complete isolation. I think the only feasible approach is to translate the DWARF info into CV info at a lower level, perhaps after the initial COFF object file containing DWARF has been emitted.

Okay, so CV isn’t supported, not sure where I got that idea >_<
Hmmm, okay, well I think I’m back where I started using the MinGW toolchain in that case…

Oh, it’s all so problematic :wink:

I’d also argue that the VS debugger is possibly the single biggest productivity enhancement offered by the IDE :wink:

And yeah, I’m in the situation where I need to link against MSVC built code, so I need PDB at the end of the day.

Your approach would be really handy in other cases though, DWARF plugin for VisualStudio would be a generally useful tool.

From what I was able to gather while looking into a debugger plugin, the existing user interface would drive all debuggers, thus the user should have more or less the same debugging experience with any fully implemented plugin.

This sounds like what WinGDB does. As I understood it, there is a problem with WinGDB, where they said they weren’t able to actually implement their debugger plugin without implementing a custom project type, which mutually excludes the Visual Studio build architecture.

/Z7, that’s the one. Maybe this approach can be used by LLVM? I presume LLVM is capable of producing CV info already? Maybe this configuration is already possible?
It’d be interesting to try it out, CV in the COFF objects, and see if the linker makes sense of it at link time…

I was able to get clang to produce COFF files with embedded DWARF debug relatively easily, which produces executables debuggable via the MinGW tool-chain.

This sounds effectively identical to what I have now using MinGW GCC to produce COFF binaries with DWARF debug info, and then running cv2pdb after linking to extract a PDB from the binary. It works, but it means I can’t link against MSVC libs/objects because of the conflicting debug info formats. :confused:

To support another debug format would be difficult I think, though I’m no expert on the subject. Currently LLVM internally represents everything more or less directly in DWARF. All of the debug meta-data attached to the IR is a slightly higher representation of DWARF data-structures. While there is a debug info builder class the insulates front ends from the details of DWARF to some extent, it is not complete isolation. I think the only feasible approach is to translate the DWARF info into CV info at a lower level, perhaps after the initial COFF object file containing DWARF has been emitted.

Okay, so CV isn’t supported, not sure where I got that idea >_<
Hmmm, okay, well I think I’m back where I started using the MinGW toolchain in that case…

Oh, it’s all so problematic :wink:

It might be feasible to convert DWARF to CV within the object file prior to linking, then you should be able to link against MSVC libraries.

I’d also argue that the VS debugger is possibly the single biggest productivity enhancement offered by the IDE :wink:

And yeah, I’m in the situation where I need to link against MSVC built code, so I need PDB at the end of the day.

Your approach would be really handy in other cases though, DWARF plugin for VisualStudio would be a generally useful tool.

From what I was able to gather while looking into a debugger plugin, the existing user interface would drive all debuggers, thus the user should have more or less the same debugging experience with any fully implemented plugin.

This sounds like what WinGDB does. As I understood it, there is a problem with WinGDB, where they said they weren’t able to actually implement their debugger plugin without implementing a custom project type, which mutually excludes the Visual Studio build architecture.

This maybe why google seems to have abandoned the idea of building a debugger plugin.

/Z7, that’s the one. Maybe this approach can be used by LLVM? I presume LLVM is capable of producing CV info already? Maybe this configuration is already possible?
It’d be interesting to try it out, CV in the COFF objects, and see if the linker makes sense of it at link time…

I was able to get clang to produce COFF files with embedded DWARF debug relatively easily, which produces executables debuggable via the MinGW tool-chain.

This sounds effectively identical to what I have now using MinGW GCC to produce COFF binaries with DWARF debug info, and then running cv2pdb after linking to extract a PDB from the binary. It works, but it means I can’t link against MSVC libs/objects because of the conflicting debug info formats. :confused:

To support another debug format would be difficult I think, though I’m no expert on the subject. Currently LLVM internally represents everything more or less directly in DWARF. All of the debug meta-data attached to the IR is a slightly higher representation of DWARF data-structures. While there is a debug info builder class the insulates front ends from the details of DWARF to some extent, it is not complete isolation. I think the only feasible approach is to translate the DWARF info into CV info at a lower level, perhaps after the initial COFF object file containing DWARF has been emitted.

Okay, so CV isn’t supported, not sure where I got that idea >_<
Hmmm, okay, well I think I’m back where I started using the MinGW toolchain in that case…

Oh, it’s all so problematic :wink:

It might be feasible to convert DWARF to CV within the object file prior to linking, then you should be able to link against MSVC libraries.

Yeah okay. So short of a concerted effort to properly support PDB, this sounds like the most plausible option going forwards.
I’ll dig around tomorrow, I wonder if there are any tools to do this already, or if cv2pdb can be adapted perhaps.

I’d also argue that the VS debugger is possibly the single biggest productivity enhancement offered by the IDE :wink:

And yeah, I’m in the situation where I need to link against MSVC built code, so I need PDB at the end of the day.

Your approach would be really handy in other cases though, DWARF plugin for VisualStudio would be a generally useful tool.

From what I was able to gather while looking into a debugger plugin, the existing user interface would drive all debuggers, thus the user should have more or less the same debugging experience with any fully implemented plugin.

This sounds like what WinGDB does. As I understood it, there is a problem with WinGDB, where they said they weren’t able to actually implement their debugger plugin without implementing a custom project type, which mutually excludes the Visual Studio build architecture.

This maybe why google seems to have abandoned the idea of building a debugger plugin.

Possibly. You might be interested to take a quick look at WinGDB. It may be interesting how they were able to integrate their debugger, and what they had to do to the project stuff to make it work.
WinGDB for Android shows the situation very well :slight_smile: