[cfe-dev] GSoC 2012: Static Function Blacklisting

[Erik Schwiebert]

This seems analogous to the throw(...) exception specification in c++ that causes lots of headaches, precisely because the complete closure of who calls who and who can throw what isn't known across translation units, much less static or dynamic libraries.  gcc and Visual Studio (and probably clang) treat the meaning of the decoration differently, leading to runtime behavior differences which has caused a number of bugs in code ported between the compilers.

Some commentary here:  http://cboard.cprogramming.com/cplusplus-programming/95555-why-does-cplusplus-need-throw.html

Computing the closure of who can call what in order to decide if the blacklist/whitelist is ok is pretty much the same problem, I think. Even restricting this to just clang as the initial implementing platform, this quickly grows into needing to persist state across invocations of the compiler so that said closure can be generated.  That information won't be available until the entire project is linked together; do you abort the link then, when it is discovered that foo calls bar calls m which is illegal according to foo's annotations? That might be an hour later in a build cycle, or days/months later when someone links in a new static library with the implementation of m().

Tricky!
Schwieb 

-----Original Message-----
From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Anna Zaks
Sent: Friday, March 30, 2012 9:01 AM
To: Mark McCurry
Cc: cfe-dev at cs.uiuc.edu; Michael Han
Subject: Re: [cfe-dev] GSoC 2012: Static Function Blacklisting

As was mentioned before, it's important to decide how you will deal with multiple translation units.

For example, you have: foo() that calls bar() that calls m(). Each is defined in its own translation unit. m() calls a non-reentrant function and only foo is annotated as "may_only_call(reentrant)".
The options here are:
 - The user should annotate all of the functions as "may_only_call(reentrant)". Bad for the user.
 - The analyzes is done in llvm, which has an ability to link in code from different translation units. That's not what the current static analyzer is doing, so would this be a separate tool?
 - Come up with a framework of storing the intermediate results between the analyzes of different translation units. Most likely, this is the direction the current clang static analyzer will take at some point; however, this is a challenging problem.
 - Only perform the check for the callees  that are either explicitly annotated or have definitions is in the current translation unit. Unless you want to be ambitious, this is probably your best option.

Also, I think both "may_only_call" and "does_not_call" annotations would be useful. One can imagine the second being less maintenance for security checking (as in "does not perform IO/accesses network").

Cheers,
Anna.
On Mar 30, 2012, at 7:04 AM, Mark McCurry wrote:

>>> Can the annotations/attributes in clang be extended in this manner
>>> (ignoring example syntax)?
>> You can add any attributes you like but to get them up stream would be hard as adding attributes is adding language extension and Clang definitely doesn't want to include arbitrary domain specific attributes. If you take a look at the attribute definition file, the attributes there are either from standard, or Clang built in, or already available in GCC (like thread safe annotations).
>> One idea of extending attribute system is to take a look at the Clang "annotate" attribute which you can embedded arbitrary literals so technically you can get your own annotation DSL inside the "annotate" attribute.
> 
> As of so far my searching has only resulted in finding the standard
> set of __attribute__() declarations defined in clang.
> ie
> http://clang-analyzer.llvm.org/annotations.html
> http://clang.llvm.org/docs/LanguageExtensions.html
> 
> Are these the annotations you are referring to or have I overlooked something?
> ie is there an __attribute__(annotate()) ?
> 
>> 
>>> Can attributes be assigned to functions without altering the source
>>> (the library case)?
>> It is possible and what we did in our tool is to redeclare the library / 3rd party functions with annotated attributes, and in Clang Sema, merge the attributes into function types.
>> 
>>> Does this sound like a good/feasable summer of code project?
>> It should be very useful as there are many low-hanging fruits out there that could be reached by this.
>> A more ambitious goal would be to extend Clang by providing a framework to encode the attributes and the "rules" (e.g. a white/black call list of a function) so clang users could add their own domain specific checks without reinvent the wheel again.
> 
> I am not too sure how ambitious to be with the scope of this project,
> but I certainly do intend to make it an easily extended system, such
> that it will apply to a variety of use cases.
> 
> --Mark
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev