Debugging Rust programs on Windows with Visual Studio/WinDbg

[Apoch]

I work on a language project that uses LLVM as a back-end. My primary target is Windows, and one of my many goals is to provide a first-class debugging experience for Windows developers. One thing that I ran into early is that debug support (i.e. from Visual Studio, WinDbg, and other Windows-centric debuggers) relies heavily on PDB files, either directly or (in the case of non-Microsoft tools) via DbgHelp.dll.

PDBs have been notoriously opaque for years, but recently, with some source code released by Microsoft, it has become practical (albeit difficult and tedious!) to generate PDBs for other languages besides C/C++. I’ve begun documenting my efforts here and circulated the results on LLVM’s dev mailing list. A few people suggested that the Rust community may find the information useful.

In the spirit of sharing and collaboration, I’m curious if anyone is actively working on supporting VS/WinDbg for Rust debugging on Windows, and if so, if there’s any way my research in this area might be beneficial to those efforts.

Thanks,

• Mike

[larsberg]

I’m really excited to hear that you’re working on this! Having a debugging experience for Rust code in Servo and Firefox on Windows that is as good or better than the experience on Linux and macOS is really important to us.

AFAIK, the two major challenges today for Rust code are:

• Name mangling on Windows is done in GNU style, not MSVC
• No variable or type information

I’m not personally working on this, but I’d be happy to help support efforts (via contracting, rah-rah mails to upper management, etc.) in whatever way would assist.

WindowsBunny/retep998/Peter Atashian and Michael Woerister would probably know more about the current state of things here and any other efforts.

[Apoch]

I can’t promise this yet, but my first forays into encoding type data suggest that name mangling may not actually be that big of a deal. It seems like (and again I need to do more work to confirm this) arbitrary strings are more or less fine in PDB data, and the mapping from mangled names to type metadata is sufficiently flexible that you don’t need to conform to a specific scheme for a debugger to show type information for function signatures etc.

There are assumptions in PDB format about how types are encoded, but they seem to be a superset of C types (plus some extra CLR stuff and whatnot floating about) so if a given language can express enough of its type system in C signatures, the debuggers will Just Work.

Again I’m still early on in encoding type/variable data so there are probably dark corners I haven’t stumbled into yet, but that’s what I’m seeing for now. For example if you respect the platform ABI for calling conventions, WinDbg at least can probe function arguments off the stack and appropriate registers, given a correct function signature in the PDB.

[retep998]

If you use the pc-windows-msvc toolchain to compile your Rust code then the resulting binary will come with a .pdb file. If you enable debug info then LLVM will emit codeview debug info into the object files that the linker will convert into the .pdb file to improve debugging. So right now things already work fairly well, but there is still room for improvement in several areas. Mainly getting LLVM to emit better debuginfo and adding specific support in the debugger for Rust. The latter unfortunately depends on Microsoft caring enough to focus on that. LLVM support however can be improved by anyone who knows enough C++ and is willing to dive in.

[Apoch]

Do I infer correctly that this process relies on Microsoft’s LINK.EXE to generate the PDBs? Is Rust interested in moving away from a third-party linker at some point?

[retep998]

Do I infer correctly that this process relies on Microsoft’s LINK.EXE to generate the PDBs? Is Rust interested in moving away from a third-party linker at some point?

We very much rely on link.exe to link stuff for us because LLVM’s lld is nowhere near feature parity with link.exe yet. Also, we basically depend on having a full msvc installation anyway so we can have access to all the import libraries for system libraries and the CRT, so there’s no reason to not use link.exe if we know it will be there anyway.

[bruno_medeiros]

Why not use the Windows-GNU ABI Rust and debug with GDB? Is it because you need to link to MSVC libraries?

[Apoch]

The same reason the United States has not adopted the metric system. The merits of the tools are irrelevant; what people are used to on Windows is Visual Studio and (to a smaller extent) WinDbg. Getting heavy-duty adoption on a platform generally involves embracing the ecosystems entrenched on that platform.

[bruno_medeiros]

I was about to say that learning to use a new standalone debugger, like say CDT’s standalone GDB debugger is like less than 1% of the effort of learning Rust, but… … then I re-read your original post, and noticed you’re not just talking about Rust not just about your personal adoption of a debugger tool, but all your potential users since you are creating a new language. Ok, your reply makes sense then.

Well then, I know LLDB devs are working on having support for MSVC debugging: http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html . Don’t know how far ahead they are, nor how committed they are to reaching that goal in a usable, production-ready state though.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.