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

Mon Nov 11 17:41:03 PST 2019

jingham added a comment.

In D69704#1732484 <https://reviews.llvm.org/D69704#1732484>, @labath wrote:

> The part that bothers me here is that this assumes that the entirety of a module (or an least the portion of it written in the same language) uses the same version of the language. Is that true for swift? Because it definitely isn't true for c++, as you can easily mix compile units built with different `-std` flags (and most of the time it will work). So it's not clear to me how this would work for c/c++, or any other language that offers some kind of a version-independent ABI, thus, enabling one to combine different versions in a single module.  Nevertheless, since this is how swift works, it seems reasonable to have some way to access this information. However, it's not clear to me if this is the best way to do that...

This call is actually being used to tell whether the type system in a given module is compatible with LLDB, not with some other compile units in the same module or other modules in the program.  That is an issue for Swift because the type information for Swift is not stored in DWARF, but in the .swiftmodule file, which is a fancy dump of internal compiler state.  So for lldb to be able to debug a swift module, it has to have been built with exactly the same version of the swift compiler as was built into lldb, or things go very wrong.  That also answers your question about swift: you have to build all the source inputs to a Swift module with the same version of the Swift compiler.  There is a version neutral text interface file, but that is only able to describe the public interface to a module.  It allows you to build code against extant modules from different versions of the Swift compiler.  But the information about private methods are only in the binary format, and so you still need the same version of swift to glom them all together.

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.

> Another thing on my mind is the name (type system). AFAICT, this is the first mention of these words in all of `lldb/API` headers, so one would get the impression that type systems are an internal implementation detail of lldb. That's why this methods sort of jumps out in your face. Are we planning to make more type system-y stuff visible at the SB level? If not, could we make this name more generic? Maybe, IsDebugInfoCompatible (with the meaning that lldb is able to understand all of debug info (of a given language) in this module)?

IsDebugInfoCompatible is a more explicit name.  It would be cool at some point to write a TypeSystem as a pure plugin, but we're nowhere near that.  So I agree it's better to reserve TypeSystem for lldb_private if we aren't really exposing it.

Repository:
  rLLDB LLDB

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

https://reviews.llvm.org/D69704