[lldb-dev] Supporting new source languages

Keno Fischer kfischer at college.harvard.edu
Thu Jan 16 10:02:42 PST 2014


Over in the Julia (julialang.org), we're interested in this too. Our
currently planned approach is to have a custom frontend to LLDB that uses
LLDB's C++ API to do the heavy lifting, so I'm not sure how much of this is
relevant. Nevertheless, it would be great to coordinate any efforts on this
front.


On Thu, Jan 16, 2014 at 12:52 PM, Greg Clayton <gclayton at apple.com> wrote:

>
> On Jan 16, 2014, at 8:04 AM, Michael Woerister <michaelwoerister at posteo.de>
> 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
> >> lldb-dev at cs.uiuc.edu
> >> 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
> > lldb-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140116/dd010573/attachment.html>


More information about the lldb-dev mailing list