On 16.01.2014 18:52, Greg Clayton wrote:
On Jan 16, 2014, at 8:04 AM, Michael Woerister <[email protected]>
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
[email protected]
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?
I am not sure I understand the question. The Rust compiler
(github.com/mozilla/rust) uses LLVM's C API to generate LLVM IR
internally and then let's LLVM produce machine code from that. I don't
know when they started using LLVM, I've only been following the project
for a year now.
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.
OK, that sounds very promising. Thanks for the pointers!
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.
Great. I'm sure there'll be a bunch of questions in the future.
Greg
Thanks again,
Michael
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
