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
