[lldb-dev] Supporting new source languages

[Greg Clayton]

On Jan 16, 2014, at 8:04 AM, Michael Woerister <michaelwoerister at posteo.de> wrote:

> On 13.01.2014 15:04, Michael Woerister wrote:
>> Hi everyone,
>> I was wondering if it is a goal of LLDB to allow for supporting programming languages other C/C++ and Objective-C? I've been browsing the source code a bit and found that references to clang::Type are hardwired into lldb::Type. Is there an extension path that allows to sidestep Clang and use one's own type representation? Is it even feasible to try and support non-Clang languages within LLDB's architecture? That would be very interesting to me.
>> 
>> Thanks for reading!
>> -Michael
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> Nobody care to comment? Let me elaborate a bit on my reasons for asking. Since last summer I've been working on debuginfo generation for the Rust compiler (www.rust-lang.org). As the Rust compiler is LLVM based this worked out pretty well and we produce DWARF good enough to satisfy basic debugging needs.

You say you have LLVM creating Rust binaries, did you write a whole new backend?

We currently use clang as our expression parser, but that doesn't mean we can't use a different expression parser for other languages.

> However, obviously debuggers don't recognize Rust yet and print out values in the wrong syntax among other things. Some of this can be alleviated with Python extensions in LLDB and GDB, but the information available through those APIs seems to be limited (eg. it seems hard get modifiers, such as 'const' or 'volatile'). Also it would be great to allow for parsing Rust expressions in the debugger, call functions, in short: make Rust a first-class citizen of the given debugger. I'm currently trying to find out what the possibilities in this area are.

You would need to do the following:

1 - Modify ClangASTType() to support different types. Right now it contains to member variables:


    lldb::clang_type_t m_type;
    clang::ASTContext *m_ast;

But this could easily be expanded to contain other things. The "m_ast" could be switched over to a pointer union so it could be a "clang::ASTContext" or a "rust::ASTContext" (or how ever you want to represent your type. Then "m_type" can be any "void *" that can represent types in your new type system.

2 - Modify the expression parser to recognize the current language of the current compile and use your new expression parser that knows how to interact with the new type in ClangASTType()

#1 is pretty easy (few weeks), #2 is a big job (few months) unless the expression parser is still the clang expression parser we are using today.


> GDB seems to have a story for supporting new source languages but for LLDB I couldn't find anything about the topic yet. It would be great if somebody could elaborate on this, even if only saying "not a goal for LLDB" or "too early to ask for something like this".

LLDB is ready for this, we just haven't done it yet. Let me know if you have any other questions.

Greg

> 
> Thanks again,
> Michael
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev