jingham added a comment. In D69704#1742494 <https://reviews.llvm.org/D69704#1742494>, @labath wrote:
> I think this is fine. > > In D69704#1741588 <https://reviews.llvm.org/D69704#1741588>, @jingham wrote: > > > If, for instance, we decided to use .pcm files as a serialization form for > > type info you would need the same sort of check for modules backed by these > > pcm's - since the clang in lldb and the clang building the pcm would have > > to match. BTW I am NOT suggesting that would be a good idea, and this will > > probably always be a no-op for anything but Swift. > > > Hm... If I understand modules correctly (and I admit I know very little about > them), I think this actually illustrates the my reservations about this. > Assuming we were fetching type info from a pcm file etc., there is no > relationship between a module (shared library) and a pcm file... I would > imagine a module can reference multiple pcm files, and each one could be > theoretically built with a different compiler. That then brings up a question > of what does it mean for lldb to be "compatible" with the module as a whole... It doesn't seem like these are mutually exclusive. If we were being exhaustive about this we would have two levels of test, (1) is all the debug information in the module uningestible and (2) are there some CU's in the module that have debug information that lldb can't ingest. If we had (2) then a language could decide "am I able to construct types from the debug info for a module that has some broken parts?" Deciding that depends on how the debug info is laid out. If the answer is yes, then (1) would return "false if all CU's return false from (2)." if no, (1) would return "false if any CU's return false from (2)". Also, IRL if we introduce some incompatibility in the toolchain from compiler version -> lldb version, the vastly more common situation would be for all of a module to be built in an incompatible way. So having this larger scale check still seems to me useful. That lldb or some GUI using it can put up a dialog saying "This module is not compatible with lldb". If the whole module is not compatible it would be awkward to complain about it CU by CU. Then historically, in the case of swift the part that causes problems is a whole-module resource and if that is not compatible with lldb, lldb can't construct a valid TypeSystem for that module. So we didn't need to implement (2), we just did (1). But that shouldn't stop anybody from implementing (2) should the need arise. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D69704/new/ https://reviews.llvm.org/D69704 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
