Investigate replacing most of the debugger pretty-printing scripts with traits.

[eddyb]

In the case of Vec<T> and String, it would be possible to have e.g.:

impl<'a, T> DebuggerView<'a> for Vec<T> {
    type View = &'a [T];
    fn debugger_view(&'a self) -> Self::View { &self[..] }
}

impl<'a> DebuggerView<'a> for String {
    type View = &'a str;
    fn debugger_view(&'a self) -> Self::View { &self[..] }
}

We would then need:

• support for pretty-printing &[T] and &str
  • already exists in our custom pretty-printing scripts
  • long-term DWARF should allow us to express these directly (see debuginfo: How to (ideally) represent reference and pointer types in DWARF #37504)
• a way to encode <X as DebuggerView>::debugger_view in X's debuginfo
  • i.e. a symbol name, or maybe we can make symbol names based on DWARF type IDs?
• support for going through <X as DebuggerView>::debugger_view for pretty-printing
  • the method signature above should be relatively simple to call

I suspect there are better APIs that could accommodate more complex data structures, but I'm not sure what the limitation of the pretty-printer scripts are, around being able to call arbitrary functions.

There's also the possibility that we could encode this sort of information as data, instead of compiling it into functions, but that's probably a lot more work.

cc @michaelwoerister

[jonas-schievink]

How does this work when cross-compiling? Is it possible to easily strip this code from the executable to reduce its size while still being able to debug the binary (important for embedded)?

[eddyb]

@jonas-schievink You mean with remote debugging? As long as the gdb server (or however you're controlling the target) lets you call functions, this should work.

Also, for embedded, would you have dynamic allocation? Pretty printers are mostly needed in that case. And even if you do, each of these impls would be a couple instructions (at least the above ones).

[jonas-schievink]

You mean with remote debugging? As long as the gdb server (or however you're controlling the target) lets you call functions, this should work.

Ah, I see. Though this sounds like it would disrupt the target state more than the current solution. Is anything similar to this implemented by other languages?

Also, for embedded, would you have dynamic allocation?

You can, yes. I suppose in that case (if you can afford a heap) the overhead of a few instructions isn't terrible but it's still a regression nonetheless.

How would this be controlled? With -Cdebuginfo? Does that currently have any impact on generated code or is everything it adds removable with strip?

[matklad]

👍 on the approach, this is essentially what KotlinNative is doing: calling into runtime to "reflect" values

https://github.com/JetBrains/kotlin-native/blob/838cccf275b121878003d9c8c2f7600d78b10989/llvmDebugInfoC/src/scripts/konan_lldb.py#L178

https://github.com/JetBrains/kotlin-native/blob/838cccf275b121878003d9c8c2f7600d78b10989/llvmDebugInfoC/src/scripts/konan_lldb.py#L249

Production-grade DebugerView should be richer and express children.

The MVP here can be much simpler though:

• add fn debug<T: std::fmt::Debug>(value: &T, buf: *const u8, buf_len: usize)
• make sure that code, compiled with debug-info, contains instantiations of debug for all T's
• make sure that debug info is rich enough for the debugger to get symbol name for debug::<T>

[matklad]

Hm, maybe even crazier:

• expose non-generic fn debug(value: *const T, buf: *const u8, buf_len: usize)
• make that function itself look at the debug info associated with value (this might need some additional info like a frame pointer passed it)
• after figuring out the runtime-type of value, debug calls into fmt::Debug using the appropriate mangled name

That way, debugger can blindly call debug on any pointer, without containing logic for figuring out symbol name from a type.

Note that this actually can be prototyped as a crate! The only thing that the crate can't do is forcing eager instantiation of fmt::Debug, but, for a POC, it would be good enough to per-instantiate some stdlib types and provide generate_debug_printers!(HashMap<String, MyType>) macro.

[eddyb]

The problem with using fmt::Debug is that I don't know the extent of the power of Python scripts.

make that function itself look at the debug info associated with value (this might need some additional info like a frame pointer passed it)

That seems... extremely complicated, compared to the debugger which already has it.

Also, if DWARF type IDs are exposed in the Python scripts, then it should be trivial to get a per-type symbol name that way.

[bjorn3]

While I like the idea, I see two problems:

1. Do we want to run arbitrary code during debugging? It may cause an infinite loop or stack overflow. It may also just be plain slow.
2. Sometimes Debug instances hide sensitive information (eg encryption keys) to prevent accidentially leaking it. However while debugging you may want to be able to inspect it though.

[eddyb]

Oh, I would prefer if this wasn't based on fmt::Debug but rather provided access, through collections, to elements, for debug purposes. So more like &_: IntoIterator for debugging.

That is, I want the debugger to do inside, what it was doing outside, e.g. Vec.

[bjorn3]

Just a random idea: Is is possible to store &mut [MaybeUninit<T>] inside Vec<T> instead of ptr + cap or &mut [T] instead of ptr + len? That would make special casing Vec<T> inside the debugger pretty printer unnecessary.

[eddyb]

That wouldn't work for, say, HashMap. And there's no nice way to fit both capacity and length into one slice.

[michaelwoerister]

I'm not sure if there is a reliable way for calling trait methods from inside debuggers yet.

[eddyb]

@michaelwoerister We would be exposing it as a regular function with a predictable symbol name, so that we can find it from the DWARF type information (via type ID perhaps?).