Re: New GCC plugin: gcc-python-plugin
On Tue, Jun 21, 2011 at 8:33 PM, David Malcolm wrote:
> I've been working on a new plugin for GCC, which supports embedding
> Python within GCC, exposing GCC's internal data structures as Python
> objects and classes.
>
> The plugin links against libpython, and (I hope) allows you to invoke
> arbitrary Python scripts from inside a compile. My aim is to allow
> people to write GCC "plugins" as Python scripts, and to make it much
> easier to prototype new GCC features (Python is great for doing this
> kind of thing).
>
> The plugin is Free Software, licensed under the GPLv3 (or later).
>
> The code can be seen here:
>
> http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=summary
>
> and the website for the plugin is the Trac instance here:
>
> https://fedorahosted.org/gcc-python-plugin/
>
> The documentation is in the "docs" subdirectory (using sphinx). You can
> see a pre-built HTML version of the docs here:
>
> http://readthedocs.org/docs/gcc-python-plugin/en/latest/index.html
>
> It's still at the "experimental proof-of-concept stage"; expect crashes
> and tracebacks (I'm new to the insides of GCC, and I may have
> misunderstood things. I'm entirely ignoring the garbage collector, and
> I've also used a few entrypoints that aren't yet exposed in the plugin
> headers).
>
> It's already possible to use this to add additional compiler
> errors/warnings, e.g. domain-specific checks, or static analysis.
>
> One of my goals for this is to "teach" GCC about the common mistakes
> people make when writing extensions for CPython [1], but it could be
> used
> - e.g. to teach GCC about GTK's reference-counting semantics,
> - to check locking in the Linux kernel
> - to check signal-safety in APIs, etc
> - rapid prototyping
>
> Other ideas include visualizations of code structure. There are handy
> methods for plotting control flow graphs (using graphviz), showing the
> source code interleaved with GCC's internal representation, such as the
> one here:
>
> http://readthedocs.org/docs/gcc-python-plugin/en/latest/cfg.html
>
>
> It could also be used to build a more general static-analysis tool.
>
> The CPython API checker has the beginnings of this:
>
> Example output:
>
> test.c: In function ‘leaky’:
> test.c:21:10: error: leak of PyObject* reference acquired at call to
> PyList_New at test.c:21 [-fpermissive]
> test.c:22: taking False path at if (!list)
> test.c:24: reaching here item = PyLong_FromLong(42);
> test.c:27: taking True path at if (!item)
> test.c:21: returning NULL
>
> Numerous caveats right now (e.g. how I deal with loops is really
> dubious). It's disabled for now within the source tree (I need to fix
> my selftests to pass again...) It perhaps could be generalized to do
> e.g. {malloc,FILE*, fd} leaks, array bounds checking, int overflow, etc,
> but obviously that's a far bigger task.
>
> So far, I'm just doing a limited form of "abstract interpretation" (or,
> at least, based on my understanding of that term), dealing with explicit
> finite prefixes of traces of execution, tracking abstract values (e.g.
> NULL-ptr vs non-NULL-ptr) and stopping when the trace loops (which is
> just an easy way to guarantee termination, not a good one, but for my
> use-case is good enough, I hope. Plus it ought to make it easier to
> generate highly-readable error messages).
>
> Thanks to Red Hat for allowing me to devote a substantial chunk of
> $DAYJOB to this over the last couple of months.
>
> I hope this will be helpful to both the GCC and Python communities.
At the London GCC gathering last weekend we discussed how to
make our plugin API more stable. One idea was to embed a
scripting language (like for example python) and provide an
abstract interface for a subset of what plugins can do, restricting
the python interface to introspection, tuning and instrumentation.
I haven't looked at your python code yet, but at least the idea
of prototyping new GCC features that would do arbitrary code
manipulation wouldn't fall into this restriction.
Richard.
> Dave
>
> [1] see
> http://readthedocs.org/docs/gcc-python-plugin/en/latest/cpychecker.html
> and
> https://fedoraproject.org/wiki/Features/StaticAnalysisOfCPythonExtensions
>
>
>
Re: LIBGCC2_FLAGS not used by libgcc2 configure?
On 21/06/11 19:01, Ian Lance Taylor wrote: CFLAGS. CFLAGS_FOR_BUILD is for code compiled for the build system. CFLAGS is for code compiled for the host system. CFLAGS_FOR_TARGET is for code compiled for the target system. The driver and the compiler as a whole run on the host system. The build system is used for tools which are run while building the compiler, such as genrecog. Ian Thanks. That makes a lot of sense. It is now working beautifully! :)
__function_size builtin
Hello, I have added a builtin __function_size that is supposed to receive a pointer to a function and return the size, in words, that the function takes. We got it working until GCC4.5. In GCC4.5 became tricky for 2 reasons. First, GCC 4.5 removes the function if the only reference to the function is through the builtin. The way it currently works is that the builtin is converted into a label, through target_fold_builtin, and then after each function we output some code so that this label is has a value equal to the function size by subtracting two labels (current position and function label). This actually only works without assembler-linker (2 in 1). However, since GCC4.5 if __function_size(swap) is the only reference to function swap, swap is removed and then there is no function in the assembler, and the calculation of the size fails. How can I tell GCC to keep functions referenced by __function_size? The second problem is the adoption of the GNU Binutils for assembling and linking. There is a backend for our target. However, the problem is that the function size, due to relaxation, is only available at link time. I know elf has a size attribute for symbols so I was thinking about using that, however, I am unsure on how to use GCC to get it working. Any suggestions? My thought was to fold __function_size still to a special label (unique for each function) that would be then generates by as and set to the unrelaxed size of the function. Once the linker performs the required relaxation it also modifies the label value accordingly. Cheers, -- PMatos
Re: __function_size builtin
"Paulo J. Matos" writes: > My thought was to fold __function_size still to a special label > (unique for each function) that would be then generates by as and set > to the unrelaxed size of the function. Once the linker performs the > required relaxation it also modifies the label value accordingly. You don't need to do that, you just need to tell the assembler to not fully resolve the difference between two text symbols, but to leave it to the linker as a PC-relative reloc. In gas you typically do this by defining DIFF_EXPR_OK in your config/tc-CPU.h file. Ian
Re: C++ member function template id not matching linkage name (PR debug/49408)
Well, the basic issue is that the "linkage name" is produced by libiberty/cp-demangle.c and the DW_AT_name is produced by gcc/cp/error.c, and they don't always agree on the same pretty-printed representation of a C++ expression. For this case, The function linkage name has prefix: K<&(S::m(int))> This isn't actually valid C++ syntax, so the demangler should be adjusted. Or maybe it is not a bug and one just has to accept the function prefix may not match its struct/class name? This would also be a good idea, for robustness when this kind of issue crops up. Jason
Re: New GCC plugin: gcc-python-plugin
On Wed, 22 Jun 2011 08:19:17 +0200
Jakub Jelinek wrote:
> You could just:
> #include "ggc.h"
>
> static void my_walker (void *arg ATTRIBUTE_UNUSED)
> {
> /* Ignore argument, as it is dummy */
> /* Walk all the still live python objects here and if they reference
> GCC GC objects, call
> ggc_test_and_set_mark (ptr);
> on each of them. */
> }
>
> static struct ggc_root_tab myroot = { "", 1, 1, my_walker, NULL };
>
> ...
> init_plugin (...)
> {
> ...
> ggc_register_root_tab (&myroot);
> ...
Perhaps a simpler alternative might be to use the PLUGIN_GGC_MARKING event, it
was designed for such use (and MELT actively uses it).
Cheers
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Re: __function_size builtin
On 22/06/11 16:23, Ian Lance Taylor wrote: You don't need to do that, you just need to tell the assembler to not fully resolve the difference between two text symbols, but to leave it to the linker as a PC-relative reloc. In gas you typically do this by defining DIFF_EXPR_OK in your config/tc-CPU.h file. Thanks, I will give it a try. In order to tell GCC not to remove the function referenced by __function_size() builtin, I found the FUNCTION_DECL and did TREE_USED() = 1 however this didn't help because the function was removed nonetheless. I thought this was the same as using __attribute__((used)) on a function declaration (which works). -- PMatos
Re: __function_size builtin
On 22/06/11 17:34, Paulo J. Matos wrote: I thought this was the same as using __attribute__((used)) on a function declaration (which works). DECL_PRESERVE_P(node) = 1; seems to be what I wanted. :)
Re: C++ member function template id not matching linkage name (PR debug/49408)
On Wed, Jun 22, 2011 at 10:42 AM, Jason Merrill wrote: > Well, the basic issue is that the "linkage name" is produced by > libiberty/cp-demangle.c and the DW_AT_name is produced by gcc/cp/error.c, > and they don't always agree on the same pretty-printed representation of a > C++ expression. > > For this case, > >> The function linkage name has prefix: K<&(S::m(int))> > > This isn't actually valid C++ syntax, so the demangler should be adjusted. I agree this isn't valid C++ syntax. However, it is a syntax used in certain popular frameworks, e.g. QT signal/slots, and it unambiguously tells in a readable manner what function is intended from overload resolution perspective. -- Gaby
Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
On Monday, June 20, 2011 03:01:47 PM Jakub Jelinek wrote: > The first release candidate for GCC 4.6.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.1-RC-20110620 > > and shortly its mirrors. It has been generated from SVN revision 175201. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. PR49407 - mingw / impossible .dll debug. PR47308#c17 - mingw / problems with mixing dwarf-2/dwarf-4 objects.
Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
On Wed, Jun 22, 2011 at 11:21:16PM +0200, Paweł Sikora wrote: > On Monday, June 20, 2011 03:01:47 PM Jakub Jelinek wrote: > > The first release candidate for GCC 4.6.1 is available from > > > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.1-RC-20110620 > > > > and shortly its mirrors. It has been generated from SVN revision 175201. > > > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux and i686-linux. Please test it and report any issues to > > bugzilla. > > PR49407 - mingw / impossible .dll debug. > PR47308#c17 - mingw / problems with mixing dwarf-2/dwarf-4 objects. Are these regressions from 4.6.0 release? If not, they don't look like 4.6.1 release blockers. Jakub
Re: [GCC steering committee] I'd like to be maintainer for Linux/x86 platform
"H.J. Lu" writes: > Apparently, there is no GCC maintainer for Linux/x86 platform. I have > been working on GCC, as well as binutils and C libraries, for Linux/x86 > over 20 years. I ported GCC, binutils and the C library to Linux/x86. I > like to be appointed as maintainer for Linux/x86 platform. H.J., you're a good developer, but I'm concerned that you commit patches too quickly without fully considering all the issues. You are quick to update your changes as well, but this leads to churn which has its own problems. I would be comfortable saying that you should have the ability to approve other people's patches for Linux/x86 (other people who don't work closely with you, at any rate), but I'm not entirely comfortable saying that you should be able to commit your own patches without review. Sorry to be blunt. Ian
Re: __function_size builtin
"Paulo J. Matos" writes: > On 22/06/11 17:34, Paulo J. Matos wrote: >> I thought this was the same as using __attribute__((used)) on a function >> declaration (which works). >> > > DECL_PRESERVE_P(node) = 1; > > seems to be what I wanted. :) I always wondered what that was for. Ian
Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
On Tue, Jun 21, 2011 at 1:01 AM, Jakub Jelinek wrote: > The first release candidate for GCC 4.6.1 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.1-RC-20110620 > > and shortly its mirrors. It has been generated from SVN revision 175201. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. It bootstraps C, C++ and Fortran in a ARM Cortex-A9 and ARMv5TE configuration. The test results are here: http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg02632.html http://gcc.gnu.org/ml/gcc-testresults/2011-06/msg02633.html with more detail here: http://builds.linaro.org/toolchain/gcc-4.6.1-RC-20110620/logs/ Ramana or Richard, could you have a read over the results please? -- Michael
Re: [GCC steering committee] I'd like to be maintainer for Linux/x86 platform
On Wed, Jun 22, 2011 at 3:25 PM, Ian Lance Taylor wrote: > "H.J. Lu" writes: > >> Apparently, there is no GCC maintainer for Linux/x86 platform. I have >> been working on GCC, as well as binutils and C libraries, for Linux/x86 >> over 20 years. I ported GCC, binutils and the C library to Linux/x86. I >> like to be appointed as maintainer for Linux/x86 platform. > > H.J., you're a good developer, but I'm concerned that you commit patches > too quickly without fully considering all the issues. You are quick to > update your changes as well, but this leads to churn which has its own > problems. I would be comfortable saying that you should have the > ability to approve other people's patches for Linux/x86 (other people > who don't work closely with you, at any rate), but I'm not entirely > comfortable saying that you should be able to commit your own patches > without review. > My direct motivation is to use DT_INIT_ARRAY on Linux/x86. I have worked on all areas of DT_INIT_ARRAY, including specification as well as implementations in assembler, linker and glibc. My GCC patch hasn't been reviewed for many months. It appears to me that no GCC maintainers seem interested or have capability to review platform specific support for Linux/x86. If I am wrong, please let me know what I can do to make Linux/x86 to use DT_INIT_ARRAY. Thanks. -- H.J.
