gcc-python-plugin February 2013

gcc-python-plugin@lists.stg.fedorahosted.org

4 participants
4 discussions

I've merged the "proposed-plugin-api" branch into "master"
by David Malcolm 28 Feb '13

28 Feb '13

I'm working on adding support for using the plugin with gcc 4.8 prereleases, and so it was time to "bite the bullet" and merge the "proposed-plugin-api" branch. This adds a "gcc-c-api" subdirectory: an intermediate C layer that's intended to shield the plugin from changes to GCC's own API (and hopefully eventually become an API for all GCC plugins to use). The 4.7 vs 4.8 differences can live there. I also plan a big symbol renaming: given that all of the gcc-c-api's symbols begin with gcc_, it's somewhat confusing to have symbols within the plugin proper that use such naming. So I plan to rename plugin symbols so that they are prefixed with PyGcc and use CamelCase_WithOneUnderscore, like Python itself. (this is a slight violation of PEP 7 in that you're not meant to use "Py" as a prefix, but I don't see it being an issue). This should make it easy to distinguish the gcc-c-api layer (lower_case_with_multiple_underscores) from the python plugin layer (CamelCase_WithOneUnderscore). Dave

1 1

Fwd: plugin to replace CHAR* with a a"smart pointer string" ??
by y a 10 Feb '13

10 Feb '13

Hi all**** ** ** I am simply awed by the gcc-python-plugin ;) **** It looks like a fantastic effort**** ** ** However, I cant find any sample which actually modifies the original C program**** ** ** For example, how to add a runtime reference count to each CHAR * Obviously, this is a large, long term project**** For C++, this replaces CHAR* with an object**** For C, I might do a simpler effort and just add an additional counter variable for each char* **** ** ** But is the python-plugin even suitable for this or should I go for a native gcc plugin ?**** It will be great to get any links to something similar ** ** ** ** Yaniv**** ** **

3 2

plugin to replace CHAR* with a a"smart pointer" ??
by y a 10 Feb '13

10 Feb '13

On Feb 10, 2013 11:20 AM > Hi all > > > > I am simply awed by the gcc-python-plugin ;) > > It looks like a fantastic effort > > > > However, I cant find any sample which actually modifies the original C program > > > > For example, how to add a reference count to each CHAR * > > Obviously, this is a large, long term project > > For C++, this replaces CHAR* with an object > > For C, I might do a simpler effort and just add an additional counter variable for each char* > > > > But is the python-plugin even suitable for this or should I go for a native gcc plugin ? > > It will be great to get any links to something similar > > > > Yaniv > yaniv

1 0

RFC: "firehose" : an interchange format for static code analysis results
by David Malcolm 05 Feb '13

05 Feb '13

Short version: there's a new branch of gcc-python-plugin named "firehose", which adds a new external dependency on a new "firehose" package for use by the "libcpychecker" functionality. I hope to merge this into master once the churn-rate within the firehose API subsides. Long version: I've been working on running various static analysis tools on a large subset of the packages in Fedora, trying to coerce the results into a consistent output format, so that I can build a tracking tool (e.g. "what new warnings were caused due to this commit?") I'm calling my format "firehose" (since reading reports from some code analysis tools can feel like "drinking from a firehose"). It can be seen at: https://github.com/fedora-static-analysis/firehose (Free Software, GPLv3 or later) You can see some examples here: https://github.com/fedora-static-analysis/firehose/tree/master/examples It's XML so that it can be easily validated: there's a RELAX-NG schema here: https://github.com/fedora-static-analysis/firehose/blob/master/firehose.rng Essentially a code issue is a message, with additional metadata (such as file/line/column, optional CWE identifier), and optionally a trace of execution to reach the error (so that an analysis tool can identify e.g. that a memory leak happens on a particular error-handling path after once through a loop, or whatever, potentially including a view of the changing variables in the code). The format's not set in stone yet (hence this RFC) - anything I've missed? I have parsers: * for GCC warnings (textual parsing, assuming LANG=C) * for clang-analyzer (the --plist format) * for cppcheck (its XMLv2 format). There's also a Python API and extensive unit tests (though the API is not set in stone yet either). I've created a "firehose" branch of gcc-python-plugin in which the cpychecker uses the firehose API as its internal representation of errors, using that to emit gcc warnings and generate HTML trace reports (I plan to refactor the error trace visualization code from out of my gcc-python-plugin and into the firehose thing, so that other projects can use it). It can thus "natively" emit XML. My plan is for this to replace the JSON experiments from https://lists.fedorahosted.org/pipermail/gcc-python-plugin/2012-March/00022… My plan is to merge this into master, adding the firehose dependency (for the cpychecker parts of the source tree, at least), though I can't do this until firehose achieves some level of API stability... and an official tarball release :) Hope this of interest - would anyone here be interested in using this in their own analysis scripts? Dave FWIW you can see some notes on what I'm building with this at http://lists.fedoraproject.org/pipermail/devel/2012-December/175232.html http://lists.fedoraproject.org/pipermail/devel/2013-January/176872.html http://lists.fedoraproject.org/pipermail/devel/2013-January/177633.html

2 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gcc-python-plugin February 2013