CC @golang/runtime @golang/windows

Is there some kind of spec or official documentation for PDB? The closest I can find is this now-archived Microsoft GitHub repo.

I will ask if there is any better documentation.

@randomascii go.1.21 introduced support for windbg - see #57302 for details. Make sure you build your exes with go.1.21.

I do not know anything about windbg or ETW to help with your issue, but hopefully @qmuntal knows more and will comment.

Alex

Not sure if it is helpful but there is also a way to convert DWARF into PDB with cv2pdb

Converting DWARF to PDB would be fine as long as the necessary debug directory is in the PE file to point to the PDB. For instance, here is the debug directory for Chrome:

Debug Directories

    Time Type        Size      RVA  Pointer
-------- ------- -------- -------- --------
64E8F817 cv            60 0028727C   28607C    Format: RSDS, {ADFEBF32-F6DA-AEA4-4C4C-44205044422E}, 1, C:\b\s\w\ir\cache\builder\src\out\Release_x64\initialexe\chrome.exe.pdb
64E8F817 dllchar        4 002872DC   2860DC

The GUID, age (the '1'), and the PDB name are sufficient to let debuggers and profilers know when they have found the correct PDB. It also give a way of finding the PDB in a symbol server.

@randomascii go.1.21 introduced support for windbg - see #57302 for details. Make sure you build your exes with go.1.21.

Ah - interesting. Having support for stack unwinding is also important for debugging and profiling. I'm glad that this has been done.

PDB support to let tools find symbol names is probably simpler than the stack unwinding task, I would guess, and would complement the stack unwinding very nicely.

From an lexan (clang-cl) team member:

We wrote https://llvm.org/docs/PDB/index.html back then. The llvm-pdbutil and llvm/lib/DebugInfo/{PDB,MSF} code is probably useful.

https://github.com/microsoft/microsoft-pdb was the reference code they open-sourced for us.

I would say that making PDBs is hard, but generating the CodeView debug info that goes into the object file prior to linking is very easy. If Go has a mode that produces relocatable COFF object files and the final PE link is handled by MSVC link.exe or lld-link.exe, like a mode for statically linking together Go and C++ code, that would be a significant shortcut to generating PDBs.

Getting function names, or public symbols, is probably a matter of emitting S_GPROC32_ID records into a .debug$S section, and the record format is in the cvinfo.h header. You can also check Clang's output on godbolt to see the assembly directives for comparison. It has comments to try to make the records a bit more readable.

The next thing you would want is line tables, and I couldn't find any docs for that. The best reference is probably in LLVM's assembler in MCCodeView.cpp. That's not needed for profiling, so that is out of scope for this issue, but very nice to have.

You can use llvm-pdbutil dump -all foo.obj (portable LLVM tool) or cvdump.exe (Microsoft tool) to dump the records and check if you're generating the right data.

First of all, 100% agree with this proposal. I have done some work (together with @dagood) to generate PDBs out of Go debug metadata, and it is already proving to be very handy when debugging syscalls/cgo on Windows.

Go.1.21 introduced support for windbg - see #57302 for details. ... I do not know anything about windbg or ETW to help with your issue, but hopefully @qmuntal knows more and will comment.

Go 1.21 do contain SEH unwinding information, which is a requirement for getting meaningful stack traces in WinDbg and friends. SEH has its limitations though: it is not designed as a debugging mechanism, its primary goal is to support exception handling. For example, it doesn't contain function names nor information about inlined functions. On the other hand, CodeView and PDB are designed explicitly to contain debugging metadata.

We wrote https://llvm.org/docs/PDB/index.html back then. The llvm-pdbutil and llvm/lib/DebugInfo/{PDB,MSF} code is probably useful.

https://github.com/microsoft/microsoft-pdb was the reference code they open-sourced for us.

I've written a minimal PDB writer that can generate accurate stack traces for Go binaries (not open sourced yet) only using microsoft-pdb and LLVM's codebase, so yes, it is possible for Go to fully support PDB files by only looking at public documentation.

Not sure if it is helpful but there is also a way to convert DWARF into PDB with cv2pdb

cv2pdb can only generate the subset of information that PDB and DWARF share. It would be a pity that an hypothetical Go PDB file would be limited to that. For example. PDB can contain source file checksums, while DWARF can't (AFAIK), and inside Microsoft it is a requirement to generate PDBs with those checksums wherever possible.

If Go has a mode that produces relocatable COFF object files and the final PE link is handled by MSVC link.exe or lld-link.exe, like a mode for statically linking together Go and C++ code, that would be a significant shortcut to generating PDBs.

Go already generates COFF object files when using external linking, the problem is that, on Windows, it only supports GCC-like toolchains, which doesn't support PDB. IMO writing PDBs is hard, but easy to maintain once you have it, as the format is almost written in stone, it doesn't change. If Go hard built-in support for writing PDB files, then it could generate PDB files when using internal linking or with external linkers that don't support PDB.