jingham 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. I see where you are going... Im my head, the plugin hierarchy for runtimes goes LanguageRuntime -> CPPLanguageRuntime -> ItaniumABILanguageRuntime. I've been calling all those "parts of the plugin for language runtimes". LanguageRuntime is the generic plugin interface, and currently CPPLanguageRuntime (and ObjCLanguageRuntime...) are also being treated as "generic parts of the LanguageRuntime plugin". Then ItaniumABILanguageRuntime.h is an instance of the plugin. Then the generic plugin interface files live out of the Plugin hierarchy and are free game, and the instances are in Plugins and should not be included from generic code. 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 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... 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. 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
