[Lldb-commits] [PATCH] D69704: [lldb] Add IsDebugInfoCompatible method to SBModule to allow checking compatibility between language versions

[Jim Ingham via Phabricator via lldb-commits]

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