The Include Macro
by Nicholas Pasternack
The following header does not work on all UNIX machines or machines running multiple versions of python: #include <Python.h>
Depending on what version of Python you use, the header needs to change to: #include <python(version).(release)/Python.h> For instance, if you have python 2.7, the include line should read: #include <python2.7/Python.h>
To the best of my knowledge, there are no Macros from the gcc that define the Python version the user is running. However, I know the following will be compatible with Mac computers:
#ifdef __APPLE__
#include <python2.6/Python.h>
#else
#include <Python.h>
#endif
I think there should be a short explanatory note in the README describing how to change the include line; if the user has multiple versions of Python, the code will not compile unless you specifically state what version of Python to use in the include line.
Nick
11 years, 11 months
Need help debugging plugin
by Emílio Wuerges
Hi,
I'm using gcc-python-plugin in my pass for x86_64 happily until now.
But now I'm trying it to use it for arm and I get this error message:
ew@arrakis:~/work/mibench/security/sha$
/home/ew/work/sca-python/bin/gcc-with-ipet -Wall -c sha_driver.c
cc1: error: fail to initialize plugin
/home/ew/gcc-python-plugin/gcc-python-plugin/python.so
Can someone tell me what should I do to debug this error? I have no
idea how to start.
If you are curious this is how I'm using gcc-python-plugin
All I did in my script was to change the gcc to arm-linux-gnueabi-gcc
wich comes with ubuntu:
ew@arrakis:~/work/mibench/security/sha$ cat
/home/ew/work/sca-python/bin/gcc-with-ipet
export SCAPYTHON=/home/ew/work/sca-python
export PYTHONPATH=$SCAPYTHON
export LD_PRELOAD=libpython2.7.so
export CC=arm-linux-gnueabi-gcc
#export CC=gcc
$CC -fplugin=/home/ew/gcc-python-plugin/gcc-python-plugin/python.so
-fplugin-arg-python-script=$SCAPYTHON/ipet.py -O2 $@
Both of them are configured very similarly:
ew@arrakis:~/work/sca-python$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
ew@arrakis:~/work/sca-python$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6.1/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix
--with-gxx-include-dir=/usr/arm-linux-gnueabi/include/c++/4.6.1
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16
--with-mode=thumb --disable-werror --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=arm-linux-gnueabi --program-prefix=arm-linux-gnueabi-
--includedir=/usr/arm-linux-gnueabi/include
--with-headers=/usr/arm-linux-gnueabi/include
--with-libs=/usr/arm-linux-gnueabi/lib
Thread model: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
Should I check anything else?
[]'s
Emilio Wuerges
ECL - Embedded Computing Lab
UFSC - Universidade Federal de Santa Catarina
Brasil
12 years
What's new with the python plugin
by David Malcolm
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...
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
12 years
