[lldb-dev] Rust language support question

[Tom Tromey via lldb-dev]

>>>>> "Jim" == Jim Ingham <jingham at apple.com> writes:

Jim> I naively thought this would make support for Rust weak, but folks
Jim> on Stack Overflow say it actually works pretty well for viewing
Jim> variables (using "frame var" or lldb's ValueObject's).  Stepping
Jim> and so forth apparently seemed to be working okay as well.
Jim> Depending on how far off this actually is, you might be able to
Jim> reuse the Clang TypeSystem and do mutatis mutandis for the
Jim> differences?  That would certainly be a lot simpler than inventing
Jim> another type representation.

I'm already pretty far down the road of having a type implementation for
Rust.  You can see the work in progress here:

    https://github.com/tromey/lldb/tree/rust

I took this approach because Rust really does need its own system.  For
example the changes coming for better handling Rust enums will end up
using DWARF constructs (DW_TAG_variant) that don't appear in C++.
There are other differences, too.

And BTW if anyone is going to FOSDEM, I'll be talking about this there.

Jim> Another little quirk of lldb that might affect your planning is that
Jim> unlike gdb, we don't have full calling-convention emulation in lldb at
Jim> present.

Thanks.  I was aware of this but hadn't looked into the details yet.

Jim> The way we get around this in lldb is that we marshal the inputs to
Jim> the expression as well as the return type into an lldb-defined struct
Jim> we cons up for the expression.  Then we write a wrapper function that
Jim> contains the expression but uses the input values from the argument
Jim> struct.  That way we only need to call a function that gets passed in
Jim> a pointer to this argument struct, which tends to be pretty easy to
Jim> do. Then we JIT and insert that function, create the input argument
Jim> structure and call our wrapper function.

Is this an approach I could take as well?  I guess my plugin could
convert expressions to LLVM code easily enough.  Or even C I suppose.

Tom