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

[Pavel Labath via Phabricator via lldb-commits]

labath added a comment.

In D69704#1742638 <https://reviews.llvm.org/D69704#1742638>, @jingham wrote:

> 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)".


Right, it's not that the two are mutually exclusive -- it's just that the semantics becomes fuzzier. You seem to think that the "natural" behavior would be to flag if "all" debug info is incompatible. My first though was that we should report if "any" debug info is incompatible.

> 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.

I actually don't think this is that uncommon in the c++ world. While it's true that all *user* code in a given library will likely use the same compiler, a typical module will also contain some startup/glue code taken from the libc and/or compiler support libraries. It's fairly likely that these were built with a different compiler, or at least different flags of the same compiler. And while these things will often have no debug info, there are also a lot of cases when they will (android NDK ships debug info for everything, most linux distros enable one to install it optionally, etc.)

BTW, what is the expected effect of this method returning "false"? I would expect that one can still normally use this module everywhere, only it will appear as if it contains no debug info (or just a limited subset).. Is that so?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69704/new/

https://reviews.llvm.org/D69704