[lldb-dev] Editline Rewrite : issues surround wide character handling on different platforms

[Vince Harron]

> 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.

This is one of bets things about LLDB.  I've heard from someone on the gcc
team that gdb is moving this way but haven't confirmed.

Vince



On Wed, Oct 29, 2014 at 10:33 AM, <jingham at apple.com> wrote:

>
> > On Oct 29, 2014, at 12:12 AM, Bruce Mitchener <bruce.mitchener at gmail.com>
> wrote:
> >
> > On Wed, Oct 29, 2014 at 1:46 PM, Matthew Gardiner <mg11 at 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 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
>



-- 

Vince Harron | Technical Lead Manager | vharron at google.com | 858-442-0868
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141029/74000ce1/attachment.html>