[PATCH] D75585: Add debug info support for Swift/Clang APINotes.

Wed Mar 4 14:05:29 PST 2020

aprantl added a comment.

In D75585#1906100 <https://reviews.llvm.org/D75585#1906100>, @dblaikie wrote:

> >>> In order for dsymutil to collect .apinotes files (which capture attributes such as nullability, Swift import names, and availability), I want to propose adding an apinotes: field to DIModule that gets translated into a DW_AT_LLVM_apinotes (path) nested inside DW_TAG_module. This will be primarily used by LLDB to indirectly extract the Swift names of Clang declarations that were deserialized from DWARF.
> >> 
> >> & this applies not just to dsymutil, right? Presumably it's used by debuggers when debugging using unlinked debug info, or using non-.o+dsymutil style debug info, such as when using Swift on Linux/ELF?
> > 
> > Absolutely. The end goal is for LLDB to import the APINotes, so it can access the attributes. What I'm particularly interested in right now is the Swift name attribute, which defines the name under which an (Objective-)C declaration should be imported into Swift, so LLDB can import Clang types from DWARF into Swift under the correct name.
> > 
> >> Is it worth discussing whether these apinotes should be embedded directly into the debug info, rather than referenced by file name? I guess they're /sort/ of like source files (they likely have the same distribution model - so if the source is accessible, so are the apinotes), so referencing by file name makes sense?
> > 
> > The alternative I considered was to invent explicit DWARF for all of the attribute kinds and put them on the decl in CGDebugInfo and deserialize them in LLDB and put them as attributes on the Decl. However, compared to just passing the apinotes file verbatim to Swift's ClangImporter this would be a lot more churn in upstream LLVM, as we'd need to add several new attributes to almost every type and decl kind.
>
> oh, yeah, I wasn't thinking that level of fidelity - just the whole file embedded as a string or something. But yeah, doesn't seem like that'd be especially better.

No, I don't think that would be bette, either.

> If APINotes is like a source/header file type thing (some could be user authored, others could be generated from something else, same way header/source might be generated) then it seems fine to reference it on disk.
> 
> I guess the only thing that makes me vascillate a bit is that debuggers don't usually process the source in any way - they just render it to the user. APINotes are meant to be semantically consumed by the debugger - that's where the analogy breaks down a bit for me, but not necessarily in a way that invalidates this approach.

What blurs the line here is that LLDB is not a traditional debugger in this sense. It can load clang modules and thus also processes source (or at least header files).

> APINotes seem to be much more readily machine readable (JSon, etc) than, say, C++ source (reason debuggers don't just reparse the source to get type information, etc).

Yes, though LLDB *can* parse type information from Clang modules to get at templates in the STL, etc. But it is a secondary source used for the expression evaluator, and not needed to just inspect the state of the program by looking at variables in the traditional debugger sense.

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

https://reviews.llvm.org/D75585