Re: customizable warnings with a GCC plugin

[David Brown <david at westcontrol dot com>]

On 29/04/2011 09:24, Pierre Vittet wrote:
> Hi,
>
> My name is Pierre Vittet and my GSOC application as been selected. My
> 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 somethings null" or "when I call this foo function, I
> would like it to be followed by that bar function". I will use MELT in
> order to realize this plugin.
>
> You can read the detail of my application here:
> http://pvittet.com/GSOC/GSOC.pdf .
>
> I have also started a page on the GCC wiki, it is pretty empty for now
> but is going to grow with the project:
> http://gcc.gnu.org/wiki/CustomizableWarningPlugin .
>
> For now, I am able to write simple plugins, two exemples can be found
> here (https://github.com/Piervit/GMWarn). However, that is still
> difficult to test them on real size programs. Mainly because it can be
> difficult to build a complete program using GCC MELT (the branch). For
> exemple GCC MELT has mainly been tested on C programs, so if there is a
> C++ part, it mights fails, I have got also some problems when the
> configure scripts had to check GCCMELT. There is a fresh release of MELT
> as a plugin which will simplify things, I am going to report few issues
> coming from it. I think MELT is improving , and I am confident in being
> able to compile on real programs (I could already build readline for
> exemple).
>
> So, I will be ready to start real coding of the plugin for the GSOC
> starting date (Mai 23).
> For the moment I would like to give the following monitoring opportunity
> to the user:
>
> - Checking that the returned value of a call to foo function is tested
> to be (not) NULL.
> - Checking that the returned value of a call to foo function is tested
> to be (not) negative.
> - Checking that the returned value of a call to foo function is tested
> to be (not) zero.
> - Checking that a call to foo is immediately followed by a call to the
> bar function.
> - Checking that a call to foo is followed in the same function by a call
> to the bar function.
>
> My checks are limited to a function because I am going to work at the
> GIMPLE representation, and pass are run successively for each function.
> I am not sure that MELT is ready for IPA pass (or that might be
> experimental work). There is sufficient things to do with GIMPLE pass.
>
> Do you see any others interesting cases to check?
>
> Another big question: For this type of plugin, what would be the best
> position to insert my pass. For now, I try to add it just after the SSA
> pass and as it worked, I keep it at the position. Is it a good choice? I
> need a pass which is always run (or my plugin will not be inserted) and
> which has a correct GIMPLE representation.
>
> I guess the most difficult point of my project might be to organise how
> my pass will run the different checks. The user will have the
> opportunity to run different checks in one compilation. I could choice
> to make one pass for every checks.
> This would mean to have a first pass that parse the arguments and set
> the others pass (Is it possible to create new pass while we are already
> in one pass ?).
>
> The others idea would be to have just one big pass, which is able to run
> for each GIMPLE statement the different checks in parallel. I am not
> sure that would be really nice.
> What is your opinion on this?
>
>
> If you have feedbacks from what is given here, I would enjoy to read
> them. If you have some documentation which could be related to the pass
> organisation (I already had a look at the very good GCC tutorial from
> Albert Cohen (http://www.hipeac.net/node/746)) or to anything looking
> interesting for my project, it would be great.
>
> Thanks for your reading, I hope my English is not so bad.
>
> Pierre Vittet

There is a lot of interesting and useful work that could be done here. 
Melt is a nice idea, but the big barrier (for me, anyway) is the 
language - it's Lisp, which is very different to other languages that 
I've used.  Most gcc users are C or C++ programmers - while they might 
like the idea of having customised warnings or checks, it would take 
them a great deal of work to learn enough Lisp to get something useful 
from melt.  So if you manage to make something that C and C++ 
programmers can easily make use of, then that would be great.

Another problem with Melt is that it is inconvenient to install and use, 
and slow to run - if you make a layer on top of that, it will be worse. 
 This is not necessary a major issue, but it will typically mean that 
the extra checking will be done as a separate "make target" rather than 
as a standard compile option (such as is done with normal gcc warnings). 
 Of course, if Melt makes it easier to do this development then it's a 
good choice - speed issues can be looked at later, once you know the 
idea is good.

Have you also considered looking at other types of static checking?  The 
ideas you have so far are definitely interesting, but there is scope for 
much more in the same vein.  Checks aimed at spotting potential buffer 
overflows or security issues are always popular.  Another idea is to 
enforce style or coding standard checks.  Of course, complete 
implementations of such checks would keep you busy for a lot longer than 
the summer - but it might be interesting to think about.

David