[lldb-dev] Supporting new source languages

[Greg Clayton]

No, that is feasible. When running an expression we should be calling a static function that is something like:

ExpressionParser *parser = ExpressionParser::FindPlugin(ExecutionContext &exe_ctx);

The execution context contains a target, process, thread and frame, and the frame contains the current location so we can check our the language of the compile unit.

Greg

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

> Ignoring time and effort, do you see any conceptual obstacles in supporting different source languages (expression parsers, type representations) as plugins like new object file or symbol parsers?
> 
> On 16.01.2014 19:34, Greg Clayton wrote:
>> To follow up:
>> 
>> ClangASTType should really be renamed CompilerType. And then everyone can place their types into this class and all type inspection will just work.
>> 
>> Each new language that doesn't use clang for its compiler would need a new expression parser that will need to know how to play with the CompilerType. We will probably need to add accessors to ClangASTType like:
>> 
>> bool ClangASTType::IsClangType() const;
>> bool ClangASTType::IsJuliaType() const;
>> bool ClangASTType::IsRustType() const;
>> 
>> Then the expression parsers would need to make sure to check any types they find via lookups to make sure the ClangASTType is the correct type.
>> 
>> On Jan 16, 2014, at 10:02 AM, Keno Fischer <kfischer at college.harvard.edu> wrote:
>> 
>>> Over in the Julia (julialang.org), we're interested in this too. Our currently planned approach is to have a custom frontend to LLDB that uses LLDB's C++ API to do the heavy lifting, so I'm not sure how much of this is relevant. Nevertheless, it would be great to coordinate any efforts on this front.
>>> 
>>> 
>>> On Thu, Jan 16, 2014 at 12:52 PM, Greg Clayton <gclayton at apple.com> wrote:
>>> 
>>> 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
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> 
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev