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

Wed Mar 4 11:47:50 PST 2020

aprantl added a comment.

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

> > Disclaimer: This is a little awkward, since this adds DWARF support for a feature that is currently only present in swift-clang but has been proposed for upstreaming (http://lists.llvm.org/pipermail/cfe-dev/2015-December/046335.html) multiple times (http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html) and will — I believe — eventually find tis way into upstream clang.
>
> Those threads are fairly old (2015 and 2017 respectively). If this is a relevant goal/justiifcation, perhaps it should be moved forward a bit more along with this proposal. Though I'm not 100% sure it's necessary for this feature to be used in clang for it to be added to LLVM - Julia and other non-clang/non-llvm-project frontends have, to my knowledge, had features added to upstream LLVM for their use cases that were never generated by any frontend in llvm-project. (stackmap/patchpoint comes to mind?)

Correct, we have language support in LLVM for languages not in the LLVM project. But since this is a Clang feature and it has been discussed previously, I thought I should link this for context.

> Just to clarify the purpose of the feature in this thread/review: apinotes allow externally imposing attributes on functions/entities you don't own, right? (sort of the same reason as ADL in C++ - I want to say something about "swap" but I don't own the canonical swap, so I need some mechanism to do that)

Yes, apinotes are a YAML file that allows adding extra attributes to declarations in system header files without modifying those header files themselves.

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

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

https://reviews.llvm.org/D75585