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? 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 > [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
