[cfe-dev] [XRay] RFC: Adding -fxray-{always, never}-instrument=... to Clang

Dean Michael Berris via cfe-dev cfe-dev at lists.llvm.org
Fri Mar 3 03:21:43 PST 2017


> On 3 Mar 2017, at 04:14, Anna Zaks <zaks.anna at gmail.com> wrote:
> 
> Just to be 100% clear, API Notes is a clang feature it's used by the Swift project to support interoperability between Swift and C/ObjC. (For example, to store knowledge about how C APIs should be imported into Swift.) The Swift project uses a clone of llvm/clang. The clone is auto-synced with top-of-tree llvm/clang but contains several features that are currently only used by the Swift project.
> 

I think this is what I meant -- if they're in the clone of clang used in the Swift project, if (or when?) it makes it back upstream we can think about maybe also using it. I think it's very similar to what the sanitisers and XRay need for imbuing attributes with the special case list, without having to use YAML or something more structured than the simple text files.

> Here is the description of API Notes from Doug's email:
> API notes solve a not-uncommon problem: we invent some new Clang attribute that would be beneficial to add to some declarations in system headers (e.g., adding a ‘noreturn’ attribute to the C ‘exit’ function), but we can’t go around and fix all of the system headers everywhere. With API notes, we can write a separate YAML file that states that we want to add ‘noreturn’ to the ‘exit’ function: when we feed that YAML file into Clang as part of normal compilation (via a command-line option), Clang will add ‘noreturn’ to the ‘exit’ function when it parses the declaration of ‘exit’. Personally, I don’t like API notes—even with our optimizations, it’s inefficient in compile time and it takes the “truth” out of the headers—but I can see the wider use cases. If the Clang community wants this feature, I can prepare a proper proposal; if not, we’ll keep this code in the Swift clone of Clang and delete it if Swift ever stops needing it.
> I think API notes can be used by other clients in clang, such a the static analyzer. It seems that it would be directly applicable to the scenario you describe as well. If so, I would propose to merge API Notes into mainline clang.
> 
> Even though Doug mentioned (in Dec 2015) that the Swift clone might delete this functionality in the future if API Notes are not needed any more, in practice, we see that the Swift project use cases for API Notes are expanding not shrinking.

That's encouraging!

I could also imagine a means of doing a pass at the LLVM level that might be used to imbue attributes based on information gained in other passes (or even externally). One thing that some users of XRay have asked is whether it's possible to statically do a walk of the call graph and selectively do instrumentation -- i.e. remove instrumentation from other parts of the binary and only focus on the code paths that we can prove statically will be calling a specific set of functions. This could work just on the LLVM level, but would also work on the front-end in cases where the choice between "always" and "never" instrument are being made at that level.

Anyway, API Notes sounds like an interesting approach for the generic case. I'm sure other projects would find interesting uses of this when it makes it in clang proper. :)

Cheers

-- Dean




More information about the cfe-dev mailing list