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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
