On Thu, 16 Jan 2014 19:34:58 +0100, Greg Clayton <[email protected]>
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
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
