[lldb-dev] Supporting new source languages

[Carlo Kok]

On Thu, 16 Jan 2014 19:34:58 +0100, Greg Clayton <gclayton at apple.com>  
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.
>

Given all of these pretty much use DWARF, and even if they used something  
like CodeView, it would be the same idea. Wouldn't it make sense for the  
"caller side" of LLDB to have access to the debug data structures, and  
remote symbol lists, and build "expressions" from that that lldb turns  
into IR and runs?

Not sure if it's feasible to do that but at the moment it seems the clang  
evaluator works by:
setting up a dummy .c file with the expression embedded inside it. Compile  
that to IR with clang for the right triple. JIT that. Transfer it to the  
"other side", evaluate it, then get back the result.

Maybe it would be cleaner to have the evaluator be able to explore the  
dwarf debug info, build a simple expression tree from that, and get back  
the result?

Just an idea anyway. I've been trying to see how to fit my (pascal)  
language into lldb, but due to the way it's designed (the compiler), it's  
not feasible to compile a single expression/method into IR and transfer it  
over (Besides that, it's written in another language than c++).


-- 
Carlo Kok
RemObjects Software