[Lldb-commits] [PATCH] D64599: [LanguageRuntime] Move CPPLanguageRuntime into a plugin

Alex Langford via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Jul 11 15:50:36 PDT 2019


xiaobai added a comment.

In D64599#1581718 <https://reviews.llvm.org/D64599#1581718>, @jingham wrote:

> Anyway, if you can make all the generic parts of lldb not depend on the language specific - but still abstract - part of the plugin, that would be fine.  Then just LanguageRuntime.h would live in Target, and CPPLanguageRuntime would live in Plugins/Language


This is exactly where I'm trying to take things and it's why I've been shuffling things around and making things more generic.

> CPPLanguageRuntime is really only used in other plugins, so it's easy.  ObjCLanguageRuntime has a few more uses in generic code, and the SwiftLanguageRuntime has some more uses in generic code (included in 16 generic files).  That corresponds to the fact that ObjC and the Swift are systems that are increasingly more dependent on their runtimes in order for the debugger to comprehend them.  Presumably we could fix this by adding some more abstract methods to LanguageRuntime, though I'd have to do some more investigation to see how awkward that would be, particularly for swift...

ObjCLanguageRuntime has 3 more uses in "base lldb" (non-plugin libraries) that I'm trying to get rid of.

- `Core/ValueObject.cpp`: D64159 <https://reviews.llvm.org/D64159>
- `Expression/IRDynamicChecks.cpp`: D64591 <https://reviews.llvm.org/D64591>
- `Symbol/ClangASTContext.cpp`: I don't plan on removing this one. Instead, I want to move ClangASTContext out of Symbol into a plugin.

After the first 2 are moved out, I intend on moving ObjCLanguageRuntime out as well. I'm also working on SwiftLanguageRuntime in the swift-lldb repository, although a little more slowly as I wanted to get C++ and ObjC done first.

Also, as an aside, I intend on trying to get swift debugging support into llvm.org at some point. I don't think llvm.org is in a place where that can be done cleanly, and I think swift-lldb's swift-specific bits need to be pulled into plugins before it becomes a reasonable endeavor. But that's the direction I want to head in. I feel similarly about Rust support. :)

> It doesn't seem to me useful to move CPPLanguageRuntime to the instance-specific part of LanguageRuntime, if we can't also do that for ObjC and Swift.  That's just confusing.  But if as a proof of concept you can get ObjCLanguageRuntime.h out of generic code, then presumably we can also do that for Swift, and the project seems worthwhile.

I uploaded this first to get some feedback and introduce the idea of moving CPPLanguageRuntime, ObjCLanguageRuntime, and SwiftLanguageRuntime. I figured I'd get any issues out of the way with the easiest one.



================
Comment at: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:55
 #include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
+#include "Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.h"
 
----------------
jingham wrote:
> xiaobai wrote:
> > labath wrote:
> > > compnerd wrote:
> > > > xiaobai wrote:
> > > > > JDevlieghere wrote:
> > > > > > What's the benefit of making this a separate plugin, as compared to making it part of `Plugins/Language/CPlusPlus`? 
> > > > > I view LanguageRuntimes as distinct from Languages and thus I think they should go into their own plugins. However, I'm not against moving this to `Plugins/Language/CPlusPlus` if you think it would make more sense to do so for another reason (e.g. less plugins overall?)
> > > > We do need the abstraction since there are multiple C++ runtimes: c++, stdc++, MSVCPRT, stlport, etc.  Each one is slightly different.  Furthermore, libstdc++ supported the GNU and Solaris ABIs, libc++ only does itanium, MSVCPRT only does MSVC ABI.  So, we need to have some layer to differentiate between the various ABIs and just general C++ language support.
> > > That is true. However, I'm not sure whether the current boundary actually makes sense. E.g. the c++ language plugin implements pretty printers for both libc++ and libstdc++.
> > Given that those are formatters specific to the libc++ and libstdc++ implementations, I think it would make sense that those are a part of the C++ language runtime plugin(s).
> So the problem with that is that formatters don't actually require a live process to be useful.  They can be used to view static data in a not-running process.  But LanguageRuntimes currently only come from a process.  So to move the formatters to the LanguageRuntime - which does make some sense - you're going to have to change the LanguageRuntime to do some things for a target with no process and the more things when the Process gets a target.  That's not a bad change, BTW.
> 
> Anyway, that's why the formatters are a little out-of-place.
Right this makes sense to me. I think we could figure something out here, as I've dealt with needing access to LanguageRuntimes without a process. I think something can be done, but that can be left for another time I think.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D64599/new/

https://reviews.llvm.org/D64599





More information about the lldb-commits mailing list