> On Oct 29, 2014, at 12:12 AM, Bruce Mitchener <bruce.mitche...@gmail.com> 
> wrote:
> 
> On Wed, Oct 29, 2014 at 1:46 PM, Matthew Gardiner <m...@csr.com> wrote:
> On Tue, 2014-10-28 at 23:40 -0700, Enrico Granata wrote:
> > With that said, building LLDB requires building LLVM and clang as 
> > prerequisites.
> > So there definitely is a clang available if LLDB is being built.
> > I wonder if one could setup things to bootstrap a clang with gcc, and then 
> > rebuild the entire LLVM, clang, lldb toolset with that built clang.
> >
> 
> Yes, of course that's possible. But I'd argue that just makes things
> more complex, and less attractive for newcomers to the project.
> 
> Incidentally, why does lldb require clang to be built as a prerequisite?
> Given that I can use it to debug a linux binary built with gcc, why do I
> need to build another compiler along the way?
> 
> Because LLDB re-uses parts of Clang ... grep for "clang::" in the codebase 
> and you'll see a lot of it.
> 
> I personally wish it weren't quite this way and that the layering were 
> different ... but that ship may have sailed a long time ago.


I'm interested in why you say this?

Note that the ClangASTType class and the ways it gets used don't expose all 
that many details of the underlying compiler & type support.  It wouldn't be a 
huge project to make a more generic CompilerType class, and clean up this 
layering so you could plug in your own type representation.  And the interface 
to Expression parsing is pretty language agnostic, so it would also not be that 
hard to plug in another compiler front end.  Some of this work needed to be 
done for Swift, though that isn't available in the current lldb sources. 

The point of reusing parts of clang is that we shouldn't have to write another 
compiler front end to parse expressions in the debugger when we've got a 
perfectly good one in clang.  Similarly we shouldn't have to invent our own 
strategy for representing types in the languages we support when presumably the 
clang folks have already done a good job at that as well.

There are some challenges with getting a compiler to be fuzzier in the way that 
the debugger requires, but clang also needed to take on some of this challenge 
to support parsing for source code completion and some of the other similar 
tasks it does.  And though this has been work, it's been lots less work than 
writing a really accurate front-end/type representation.

And for instance, if we ever get good support for modules in C++, we could 
presumably then use that to do things like instantiate template classes for 
types that weren't instantiated in the current program, and other cool'o things 
like that which would be hard to do with some hand-built C++ parser, a la gdb.

Jim

> 
>  - Bruce
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev


_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to