Rust: No lldb/gdb pretty printers for HashMap

[jrmuizel]

These would be very handy to have.

[michaelwoerister]

PRs are always welcome! :)

[gilescope]

If no one is on this I'll take a crack at it for lldb at least...

[gilescope]

Am wondering if there's a better way to do the python lldb formatters... would it be a crazy idea to call out from python to a rust lib that bound to the std lib? That way you could cast the pointer to a hash table and not need to know what the structure of the hashmap was when pulling out the data for visualisation. In particular it wouldn't break if the internals were re-organised. Or would this be too recursive? @alexcrichton is it worth a shot?

[alexcrichton]

I don't have much experience myself with how that'd be implemented, but I'd imagine that the overhead of trying to distribute a custom .so and dealing with cross-debugged situations that things could get hairy :(. I think it's fine though to just hardcode the layout into the gdb pretty printers, we'd just update it whenever we change libstd.

[gilescope]

So close. I can identify the chunk of raw memory that holds the k/v pair (they're immediately after the array of hashes in memory), but LLDB doesn't know the type info so can't figure out where the key finishes and the value begins. Alas the marker is phantom and has a size of 0. The best I can do is print out that chunk of memory for each k/v pair as lldb doesn't seem to know anything about the types. All queries to SBType.GetTemplateArgumentType don't seem to do much for tuples... The unqualified type string shows the types of the pair as text, but mapping that to types LLDB understood would probably be unmaintainable.

[michaelwoerister]

Maybe you can extract the pointee type out of the pointer type to the chunk of memory?

[gilescope]

I think the pointer doesn't have the required type info as it's pointing to the start of the hashes rather than the pairs after that. Zooming out a little, is there an lldb branch where a rust plugin is being developed? I've checked out and built lldb and there's nothing rust specific at the moment. I'm hoping there's a c++ guru that's half way through an implementation, but its just not on trunk/head?

[tromey]

Zooming out a little, is there an lldb branch where a rust plugin is being developed?

https://github.com/tromey/lldb/tree/rust. Not ready for users yet but if you have specific issues you can file a bug to get it on my to-do list.

[ortem]

Is there any progress on this issue?

I suppose it is impossible to get the key (value) type from a HashMap, because it is even impossible to get a generic type from an empty struct S<T>. I'm not sure, but probably the compiler should use Substs from ty::Adt inside prepare_struct_metadata (from src/librustc_codegen_llvm/debuginfo/metadata.rs), like inside prepare_tuple_metadata?
@tromey could you please look at this?

[tromey]

@tromey could you please look at this?

I'm not totally sure which aspect you are thinking of here, but if you mean finding the actual types of generic parameters, I am working on that in #55010.

[estebank]

I believe that once that is merged, it should enable decoding the actual values using the type info, right? So this ticket would remain open until _that_ work is done.

[tromey]

I believe that once that is merged, it should enable decoding the actual values using the type info, right? So this ticket would remain open until that work is done.

Yes, that's correct.

[ebkalderon]

Looks like #55010 has been merged and seems to be available on stable. Has anyone started tackling this issue?

[ortem]

@ebkalderon Recently I've implemented pretty-printers for HashMap/HashSet for both lldb and gdb. I'm going to replace current rustc's pretty-printers with new ones which I develop for IntelliJ Rust, and hope I'll have enough time to make such PR soon.

[ebkalderon]

@ortem Awesome! Thanks for the rapid response. Is there any way to help speed the implementation along?

[ortem]

@ebkalderon If you'd like to help me, I'd be happy to open a very draft PR right now :) I've never contributed rustc and don't know its architecture well, so it would be really helpful if someone checks code that new pretty-printers can affect.

https://github.com/rust-lang/rust/pull/60826