[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:13:49 PDT 2019


xiaobai marked an inline comment as done.
xiaobai added a comment.

In D64599#1581620 <https://reviews.llvm.org/D64599#1581620>, @labath wrote:

> In D64599#1581598 <https://reviews.llvm.org/D64599#1581598>, @jingham wrote:
>
> > My model for this was that there was a CPPLanguageRuntime.cpp that contains everything you can implement about the CPP runtime that is independent of any particular implementation of the CPP language runtime, and then a plugin instance (in this case the ItaniumABILanguageRuntime) that contains all the bits that are specific to a particular implementation.  Then putting the CPPLanguageRuntime.cpp in Target lets you know that this has to only contain the generic parts of the runtime behavior.  That still seems to me a useful distinction.
>
>
> I think that's fine, but it does not conflict the idea of the generic parts of a cpp language runtime being a plugin also. This way the generic parts of lldb would be truly language agnostic. Then if anything wants to work with a c++ runtime, but it does not care which one, it can use CPPLanguageRuntime. And if you need a very specific runtime, you go for the Itanium thingy.


+1

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

> In D64599#1581604 <https://reviews.llvm.org/D64599#1581604>, @labath wrote:
>
> > What is the indented relationship between CPPLanguage and CPPLanguageRuntime plugins (and generally between any Language and its LanguageRuntime)? Right now you're having the CPPLanguage depend on the CPPLanguageRuntime plugin. There is no reverse dependency, so this may be fine, if that's how we intend things to be. However, it's not clear to me whether that's the right way to organize things. Intuitively, I'd expect the LanguageRuntime to depend on Language, and not the other way around...
>
>
> The nominal distinction is that the Language files contain what you can know about or need to do with a given language without having a process and thus a live runtime to query.  The LanguageRuntimes are supposed to be about what you can gather from the actual runtime, or what you need to do to handle things like "stepping into steps across ObjC method dispatch functions" or "stepping into std::function steps in to the target function".  Given this distinction you'd actually expect the two to be independent of one another, but then it turns out that in both ObjC and Swift, you can't actually know the sizes of objects, or the offsets of ivar members until you have a running process.  So things you'd think the Language would know actually require the LanguageRuntime...


I also think that Language depending on LanguageRuntime makes sense. It seems to me that in order for the Language to be able to answer questions about implementation-defined features, it must ask the language runtime for help.



================
Comment at: source/Plugins/ExpressionParser/Clang/ClangExpressionDeclMap.cpp:55
 #include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
+#include "Plugins/LanguageRuntime/CPlusPlus/CPPLanguageRuntime.h"
 
----------------
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).


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

https://reviews.llvm.org/D64599





More information about the lldb-commits mailing list