Re: [lldb-dev] Rust support in LLDB, again

[Pavel Labath via lldb-dev]

+1 to everything that Jonas said.

On 30/09/2019 18:28, Jonas Devlieghere via lldb-dev wrote:

Hi Vadim,

On Sat, Sep 28, 2019 at 4:00 PM Vadim Chugunov via lldb-dev
 wrote:


Hi,
Last year there was an effort led by Tom Tromey to add Rust language support 
into LLDB.  He had implemented a fairly complete language plugin, however it 
was not accepted into mainline because of supportability concerns.I guess 
these concerns had some merit, because this change did not survive even in 
Rust's private branch due to the difficulty of rebasing on top of LLVM 9.


Unless my memory is failing me, I don't think we ever explicitly
rejected Rust's language plugin. We removed a few other language
plugins (Go, Java) that were not maintained and were becoming an
increasing burden on the community. At the same time we agreed that we
didn't want to make the same mistake again. Some of the things that
come to mind are having a working implementation, testing, CI, etc. If
the rust community can show that they're dedicated to maintaining Rust
support in LLDB, I wouldn't expect a lot of resistance. I just bring
this up because I don't want to discourage anyone from adding support
for new languages to LLDB.


I am wondering if there's a more limited version of this, that can be merged 
into mainline:
In terms of its memory model, Rust is not that far off from C++, so treating 
Rust types is if they were C++ types basically works.  There is only one major 
problem: currently LLDB cannot deal with tagged unions, which Rust code uses 
quite heavily.   When such a type is encountered, LLDB just emits an empty 
struct, which makes it impossible to examine the contents.

My tentative proposal is to modify LLDB's DWARFASTParserClang to handle 
DW_TAG_variant et al, and create a C++ approximation of these types, e.g. as a 
polymorphic class, or just an untagged union.   This would provide at least a 
minimal level of functionality for Rust (and possibly other languages) and be a 
much lesser maintenance burden on LLDB core team.
What would y'all say?


The people that actually work on this code should answer this, but
personally I don't have strong objections to this. That said, of
course I would prefer to have a (maintained) language plugin instead.

PS: Are there other changes that live downstream that are not Rust
specific and would benefit upstream LLDB and would potentially improve
Rust debugging?

Jonas


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

Re: [lldb-dev] [Bug 25866] Gentoo Linux build breaks in some scenarios when both Python 2 and Python 3 are present

[nu quaquaraqua via lldb-dev]

Hello,
when the fix has been posted? I'm hitting it on the tarball v9.0.0

On Thu, 8 Aug 2019 at 03:15, via lldb-dev  wrote:

> Jonas Devlieghere  changed bug 25866
> 
> What Removed Added
> Status NEW RESOLVED
> Resolution --- WORKSFORME
> CC   jdevliegh...@apple.com
>
> *Comment # 1  on bug 25866
>  from Jonas Devlieghere
>  *
>
> LLDB is now fully compatible with Python 2 and Python 3, as well as SWIG 2 and
> later.
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust support in LLDB, again

[Vadim Chugunov via lldb-dev]

>
> > Unless my memory is failing me, I don't think we ever explicitly
> > rejected Rust's language plugin. We removed a few other language
> > plugins (Go, Java) that were not maintained and were becoming an
> > increasing burden on the community. At the same time we agreed that we
> > didn't want to make the same mistake again. Some of the things that
> > come to mind are having a working implementation, testing, CI, etc. If
> > the rust community can show that they're dedicated to maintaining Rust
> > support in LLDB, I wouldn't expect a lot of resistance. I just bring
> > this up because I don't want to discourage anyone from adding support
> > for new languages to LLDB.
>

Do you have any thoughts on how this support should look like?

Realistically, though, I would expect this to go about as well as the
previous two attempts you've mentioned. :(


> >> My tentative proposal is to modify LLDB's DWARFASTParserClang to handle
> DW_TAG_variant et al, and create a C++ approximation of these types, e.g.
> as a polymorphic class, or just an untagged union.   This would provide at
> least a minimal level of functionality for Rust (and possibly other
> languages) and be a much lesser maintenance burden on LLDB core team.
>

I looked at the code in more detail, and unfortunately it looks like C++
AST is not flexible enough to represent variants as polymorphic classes, so
It'll have to be just untagged unions.   But I'd love to hear otherwise
from people more familiar with that code.


> > PS: Are there other changes that live downstream that are not Rust
> > specific and would benefit upstream LLDB and would potentially improve
> > Rust debugging?
>

Nothing major I can think of.  The rest of changes seem to be pretty
Rust-specific.

My general feedback is that it would help a lot if LLDB were less C++- (and
in particular clang-) centric.  For example, right now LLDB converts
various debug info formats directly into clang AST.  As a result, other
languages are forced to re-implement debug info parsing from scratch and
soon as they need to customize anything that cannot be mapped to C/C++
concepts.   There probably needs to be some sort of language-agnostic layer
that abstracts debug info formats for use by language plugins.  If this
layer supported DWARF spec in its entirety, I expect that most languages
would need little to no customization, at least until you get to
implementing a REPL for that language.

A stable ABI for dynamically-loadable language plugins would be the best,
of course.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Rust support in LLDB, again

[Jim Ingham via lldb-dev]

> On Oct 1, 2019, at 11:54 AM, Vadim Chugunov via lldb-dev 
>  wrote:
> 
> > Unless my memory is failing me, I don't think we ever explicitly
> > rejected Rust's language plugin. We removed a few other language
> > plugins (Go, Java) that were not maintained and were becoming an
> > increasing burden on the community. At the same time we agreed that we
> > didn't want to make the same mistake again. Some of the things that
> > come to mind are having a working implementation, testing, CI, etc. If
> > the rust community can show that they're dedicated to maintaining Rust
> > support in LLDB, I wouldn't expect a lot of resistance. I just bring
> > this up because I don't want to discourage anyone from adding support
> > for new languages to LLDB.
> 
> Do you have any thoughts on how this support should look like?
> 
> Realistically, though, I would expect this to go about as well as the 
> previous two attempts you've mentioned. :(  
>  
> >> My tentative proposal is to modify LLDB's DWARFASTParserClang to handle 
> >> DW_TAG_variant et al, and create a C++ approximation of these types, e.g. 
> >> as a polymorphic class, or just an untagged union.   This would provide at 
> >> least a minimal level of functionality for Rust (and possibly other 
> >> languages) and be a much lesser maintenance burden on LLDB core team.
> 
> I looked at the code in more detail, and unfortunately it looks like C++ AST 
> is not flexible enough to represent variants as polymorphic classes, so It'll 
> have to be just untagged unions.   But I'd love to hear otherwise from people 
> more familiar with that code.
>  
> > PS: Are there other changes that live downstream that are not Rust
> > specific and would benefit upstream LLDB and would potentially improve
> > Rust debugging?
> 
> Nothing major I can think of.  The rest of changes seem to be pretty 
> Rust-specific.
> 
> My general feedback is that it would help a lot if LLDB were less C++- (and 
> in particular clang-) centric.  For example, right now LLDB converts various 
> debug info formats directly into clang AST.  As a result, other languages are 
> forced to re-implement debug info parsing from scratch and soon as they need 
> to customize anything that cannot be mapped to C/C++ concepts.   There 
> probably needs to be some sort of language-agnostic layer that abstracts 
> debug info formats for use by language plugins.  If this layer supported 
> DWARF spec in its entirety, I expect that most languages would need little to 
> no customization, at least until you get to implementing a REPL for that 
> language.

Swift has its own AST, and a separate DWARF->SwiftAST parsers, and an 
independent expression evaluator and runtime. Though the Swift support is in a 
separate repository, all the plugin code to handle an entirely non-C++ like 
language is also present in the llvm.org sources.  That requires building a 
fair bit of the compiler into lldb - which may bring up license issues for Rust 
- but it is possible.

> 
> A stable ABI for dynamically-loadable language plugins would be the best, of 
> course.

The interface for language plugins is still evolving, as we move the clang (and 
swift) dependencies out of generic code and into the plugins (shout out to Alex 
for his persistence in this effort!!!).  And I don't think the language plugins 
will ever be stable in the way the SB API's are.  They rely on too many llvm 
constructs, and those are not guaranteed to be stable.  In that sense lldb will 
be like developing with the rest of the llvm infrastructure.  Stable enough in 
API form, and factored out well enough, that keeping up with external changes 
won't be too much of a pain, but still requiring recompiles.

Jim



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

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

[lldb-dev] October LLVM bay-area social is this Thursday!

[George Burgess IV via lldb-dev]

We'll be at Tied House as usual, starting on Thursday the 3rd at 7pm!

If you can, help us plan and RSVP here:
https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyznbfb

See everyone there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev