What's new with the python plugin

David Malcolm dmalcolm at redhat.com
Thu Apr 5 18:49:38 UTC 2012


For me, libcpychecker is the primary use-case for the gcc python plugin,
and I've spent a large amount of the last few months attempting to run
it on all code linked against libpython2.7.so in the forthcoming Fedora
release, Fedora 17 (about 370 packages altogether) [1]

This has been a good torture test for the libcpychecker code: it's now
been run against hundreds of packages, and I've manually inspected the
majority of the results, and filed many bugs (though it's rather
dispiriting looking at so much buggy code!).

I've found and fixed many bugs in the libcpychecker code in the process:
for example, it now works on some C++ code (though not on all C++ code
yet).  I also started adding a "Common Mistakes" section to the
documentation:
http://gcc-python-plugin.readthedocs.org/en/latest/cpychecker.html#common-mistakes
with notes on how to fix them.

Based on this experience, I think the most important areas to fix within
this code are:
  * a big source of false positives is from the lack of interprocedural
analysis.  I hope to try and add this, based on the discussion about the
psycopg2 code we had on this list about a month ago [2]
  * finishing the new visualization the Yelp folks worked on: the error
reports from the checker need to be easier to read than the current
refcount-errors.html ones and I think their prototype is a step in the
correct direction, but it needs to be finished and integrated.
  * (more difficult) a smarter analysis engine: rather than generating a
huge transition tree and then pruning it, instead try to iteratively
solve data-flow equations, like other static analysis engines do.

FWIW, I also plan to work on an unrelated item: a plugin API for GCC
itself.  If you follow the development of gcc as a whole, you may have
see various discussions recently on the gcc mailing list about the need
for a "real" plugin API.

GCC doesn't make any guarantees yet to plugin authors about any
entrypoints that are valid to use, and GCC is about to transition
internally to C++, which makes me worry that the plugin could get
increasingly difficult to maintain against newer versions of GCC.

To ameliorate this, I've been trying out ideas for a possible GCC plugin
API within the Python plugin's git repository on fedorahosted.org, in
the "proposed-plugin-api" branch.   This is a prototype to see if we can
provide everything the Python plugin already provides, but going
internally through a new C or C++ API, in the hope that the GCC core
maintainers can agree to maintain that API (and ABI) even as the insides
change.

Thoughts?  Anyone want to get involved in any of the above?
Dave

[1] https://fedoraproject.org/wiki/Features/StaticAnalysisOfPythonRefcounts
[2] see https://fedorahosted.org/gcc-python-plugin/ticket/40



More information about the gcc-python-plugin mailing list