gcc-python-plugin April 2012

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

3 participants
3 discussions

The Include Macro
by Nicholas Pasternack 07 May '12

07 May '12

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

2 16

Need help debugging plugin
by Emílio Wuerges 18 Apr '12

18 Apr '12

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

2 5

What's new with the python plugin
by David Malcolm 05 Apr '12

05 Apr '12

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-m… 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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

gcc-python-plugin April 2012