Debug visualization of Rust data structures #160
Description
Currently VS GDB engine (GDBEng) doesn't support GDB's "pretty printers", so Strings, Vecs and other HashMaps look pretty incomprehensible in the variable inspector. I've tried several approaches to address this, but so far without much success. Still, I thought I should document them here for posterity:
- Force MI pretty-printing mode in GDB by injecting the
-enable-pretty-printingcommand via init script. Unfortunately, GDB always interprets Python-based pretty-printers as "dynamic", i.e. with an unknown number of children (even if the pretty-printer'schildren()method returns a finite sequence). This results invarobj's like this:name="var1",numchild="0",dynamic="1",has_more="1" ..., which GDBEng doesn't know how to deal with.
As far as I can see, the only way to make this approach work, is to fix the GDBEng, once Microsoft open-sources it. - Use VS's own "debug visualizers".
Alas, this doesn't work either because of the confluence of two problems:- Since GDB does not understand the
DW_AT_language=Rustattribute yet, it falls back to treating Rust modules as if they were C: all non-primitive type names are printed asstruct Foo, all namespaces are ignored, ditto for generic parameters. - On the other hand, GDBEng visualizer's type parser seems to be hard-coded for C++ types. I could not figure out a way to make it match type strings such as the above.
We could probably work around this by emittingDW_AT_language=CPlusfor Rust modules, but that seems a bit too drastic for the sake of supporting one specific IDE. Although... C++ type system is probably closer to Rust than C is, so maybe it isn't such a bad idea? I wonder what @michaelwoerister thinks about this :)
- Since GDB does not understand the
- Use LLDB rather than GDB.
Although I've managed to build LLDB for Windows without much trouble, at the moment it looks pretty raw: Python does not initialize properly, single-line stepping is broken, etc, etc. Because of the problem with Python, I could not evaluate how well (or whether at all) LLDB's "data formatters" work over the MI interface.