Skip to content

Debug visualization of Rust data structures #160

Open
@vadimcn

Description

@vadimcn

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:

  1. Force MI pretty-printing mode in GDB by injecting the -enable-pretty-printing command 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's children() method returns a finite sequence). This results in varobj'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.
  2. 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=Rust attribute yet, it falls back to treating Rust modules as if they were C: all non-primitive type names are printed as struct 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 emitting DW_AT_language=CPlus for 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 :)
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions