• CustomizableWarningPlugin

GSOC Project 2011: customizable warnings with a GCC plugin

The project is about writing a plugin allowing GCC users to add some simple warnings, being useful in their particular project. The user should be able to add rules like "when I got a call to a foo function, I would like to be sure that a check is made to monitor that it doesn't return something null" or "when I call this foo function, I would like it to be followed by that bar function". MELT will be use in order to realize this plugin.

You can get the original application proposal.

State before the project

The following mail is pretty useful to know the state of the project before the GCC coding date: http://gcc.gnu.org/ml/gcc/2011-05/msg00048.html

Code Repository

It will be in the MELT source code as a usable plugin which can be use (like an exemple).

TODO

Issue to think about

Use control flow graph information to return proper GCC information

Generally when I want to parse intermediate representation I use the MELT iterator each_bb_cfun which iterate hover each basic block of the current function. This works well but if I want to check, for exemple that the foo function can be called only once in a given function, it doesn't necessarily means that it has to appears only one time in one basic blocks. It can still appear one time in several basic blocks as long as, at the execution time only one of thoses basics blocks will be use in a single call.

for exemple:

void bar(int i){
    if(i<0){
        ...
        foo();
    }
    else{
        ...
        foo();
    }
}

If we basically parse each basic blocks, we will find 2 call to foo, while only one can be executed at each call.

This means that, I cannot just parse each basic blocks but I have to know if the two blocs can be executed simultaneously or not? I would like to know if there is any possibility to use the control flow graph to easily detect this in the gimple state (I cannot do this before because I have to know know which basic blocks is involved, so which basic block contain the foo() function).

====How the user store his options====

User can give options to the plugin in order to check for severals types of warnings. He must choose on which functions he wants checks. There might be an important number of arguments.

Idea:

• Using pragma informations in the code:
  • pro:

    • It might help to solve name mangling problems (http://en.wikipedia.org/wiki/Name_mangling)

  • cons:
    • You have to modify the source code to check something, checks are not means to be easily changed.
• Putting them as a list of arguments:
  • pro:
    • Easily editable by the user.
  • cons:
    • Possible mangle problem if is it is not C langage (we can't expect from the user to know the mangle name of the function he wants to check).
    • Arguments list might be long
• Putting them in a separate file:
  • pro:
    • Easily editable by the user.
  • cons:
    • Possible mangle problem is it is not C langage (we can't expect from the user to know the mangle name of the function he wants to check).

====How to organize the pass====

todo

====What is a usefull warning message====

todo

Contact

Student: Pierre Vittet (piervit -at- pvittet -dot- com)

Mentor: Basile Starynkevitch