Re: [lldb-dev] PDB symbol reader supports C++ only?

[Tom Tromey via lldb-dev]

> "Vadim" == Vadim Chugunov via lldb-dev  writes:

Vadim> Would you mind going into a bit more detail on what sort of
Vadim> problems an unknown language could cause?  I'd like to understand
Vadim> the issue before jumping in to fix anything.  AFAIK, in the case
Vadim> of DWARF symbols, debug info for unknown languages is still used,
Vadim> so it wouldn't be the first for LLDB...

LLDB checks for DW_LANG_Rust and uses the C++ plugin in this case.

The Rust lldb 
(https://github.com/rust-lang-nursery/lldb/commits/rust-release-70)
removes this.

If you get something working, let me know.  I'd like to incorporate it
into the Rust lldb.

Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] hashing pointers to strings

[Tom Tromey via lldb-dev]

> "Pavel" == Pavel Labath via lldb-dev  writes:

Pavel> [ Clang's emission of pubnames/pubtypes is controlled by the "debugger
Pavel> tuning" parameter. With -glldb they don't get emitted, with -ggdb,
Pavel> they do.

gdb has never read .debug_pubnames, so this setting doesn't really make
sense.

Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust language support question

[Tom Tromey via lldb-dev]

> "Pavel" == Pavel Labath  writes:

Pavel> Yes, but it still adds another manual step to the setup process, which
Pavel> means most developers will not do it. It also exposes us to a
Pavel> non-determinism coming from different versions of the rust compiler
Pavel> people will have.

I see what you mean, but if the Rust plugin isn't updated for new
versions of the Rust compiler, it just won't be very useful to Rust
developers.

This could happen, but I think the best approach here is more
communication.  If newer versions of Rust break the tests, and you don't
hear from the Rust community, ask someone what's going on.


For older versions, what I understand is that Rust doesn't remove old
toolchains.  So you can still install older ones for testing.  For
testing LLDB changes unrelated to Rust, you can just install some
known-working toolchain.  My plan is to support some reasonable range --
starting with whatever toolchain is stable at the time the Rust plugin
is ready to be used.


Mostly I'm trying to avoid writing a lot of custom DWARF tests.  That
seems like a lot of work for not a lot of benefit.  And from what I
understand (correct me if I'm wrong), I'd be the first to being doing
this, so I'd probably have to write the tooling, etc.

Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust language support question

[Tom Tromey via lldb-dev]

> "Pavel" == Pavel Labath  writes:

Pavel> To these very insightful emails from Greg and Jim, I'd just like to
Pavel> add one request. Please consider the testing strategy of the code you
Pavel> write early on. One of the problems that we have with these language
Pavel> plugins (and why we now have a separate thread considering removal of
Pavel> some of them) is that after the plugin has landed and some time has
Pavel> elapsed with no activity on it, we have no idea if it is even still
Pavel> functional without any tests.

So far I've added code in packages/Python/lldbsuite/test to support Rust
and then I have a simple Rust program that exercises the various
features of the plugin.

The Rust toolchain is very easy to install, so I don't think testing
this in the future should be too difficult.

I am not sure of the details yet, but for expression parsing, I would
like to get the external helper into "rustup" (the Rust toolchain
manager) as well.

Pavel> (maybe via llvm/DWARFYAML)

What is a good resource for learning about this?

Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust language support question

[Tom Tromey via lldb-dev]

> "Jim" == Jim Ingham  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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Rust language support question

[Tom Tromey via lldb-dev]

Hi.  I'm working on adding Rust language support to lldb.

One question that's come up is the best way to handle expression
parsing.

On the one hand, it would be convenient to reuse an existing parser --
the one that we discussed was the "syn" crate.  But, this is a Rust
program.

So then there's the question of how to ship it.  Directly using the syn
crate would mean having Rust code in-tree.  Or, perhaps the Rust parts
could be shipped as a shared library or an external executable.

Are either of these doable?  What do other language plugins do?

My original plan here was to simply make the entire language support an
external plugin.  But, from what I can tell this isn't possible -- the
necessary DWARF-related headers aren't installed.  So maybe this could
be changed?  This would provide us with the most flexibility I think.

A final idea is to do what I did for gdb, and simply write a new parser
in C++.  Doable, but for me I think a last resort.

thanks,
Tom
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev