[cfe-dev] Module Questions

Dean Sutherland dsutherland at cert.org
Sun Dec 22 11:54:10 PST 2013


Doug (and others):

I'm working on static analysis of C and C++ code, and need a mechanism for processing groups of TUs that have both:
* a known and statically complete interface (dynamic dispatch & function pointers are a different problem that need not be considered here)
* known and statically enumerable contents.

These properties would enable interesting cross-TU analyses, including some forms of sound inference across TUs.  

Reading through the various Modules information I've found (e.g.,http://clang.llvm.org/docs/Modules.html etc.), I see that Modules appear to provide about 90% of what I'm looking for. Specifically, there appears to be a map between modules and the headers that comprise their interfaces. By extension, this map also seems to identify some header files that are excluded from the interface of a module.

What I haven’t seen is a map between modules and the TUs that implement them.  For my purposes, such a map would indicate (a) for a given TU, which module (or modules) it is part of (if any), or (b) for a given module, which TUs provide its implementation. In principle, one could build the entire mapping between TUs & modules given a complete set of either of (a) or (b).

Does such a map exist? Have I just failed to spot it? If not, would something along these lines be an interesting new capability (opt-in only, of course)?

In addition, would it make sense to allow a TU to claim that it is part of the implementation of a module, perhaps via an attribute in the source code? Such a claim could be useful for static analysis even if it were totally ignored by the rest of the compiler and build system.  Indeed, I'd expect such an attribute would indeed be ignored by the rest of the system for the foreseeable future.

Dean Sutherland
dsutherland at cert.org

P.S.  Doug — we spoke briefly about this at the LLVM Dev conference in November. This is the first of several long-delayed follow-up messages.





More information about the cfe-dev mailing list