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