[lldb-dev] Supporting new source languages
ck at remobjects.com
Thu Jan 16 12:45:38 PST 2014
On Thu, 16 Jan 2014 19:34:58 +0100, Greg Clayton <gclayton at apple.com>
> 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
> 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
> 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
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++).
More information about the lldb-dev