From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13235 invoked by alias); 30 Mar 2012 23:17:08 -0000 Received: (qmail 13226 invoked by uid 22791); 30 Mar 2012 23:17:07 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 30 Mar 2012 23:16:49 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2UNGnU0019619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Mar 2012 19:16:49 -0400 Received: from [10.3.224.243] (vpn-224-243.phx2.redhat.com [10.3.224.243]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2UNGmeB022801; Fri, 30 Mar 2012 19:16:48 -0400 Subject: Re: Proposed plugin API for GCC From: David Malcolm To: Richard Guenther Cc: gcc@gcc.gnu.org Date: Fri, 30 Mar 2012 23:17:00 -0000 In-Reply-To: References: <1333054687.31165.65.camel@surprise> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Message-ID: <1333149367.2447.29.camel@surprise> Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg00554.txt.bz2 On Fri, 2012-03-30 at 14:14 +0200, Richard Guenther wrote: > On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm wrote: > > I had a go at writing a possible plugin API for GCC, and porting parts > > of my python plugin to it: > > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=commitdiff;h=36a0d6a45473c39db550915f8419a794f2f5653e > > > > It's very much at the "crude early prototype" stage - all I've wrapped > > is part of CFG-handling - but the important thing is that python plugin > > *does* actually compile against this, and many of its selftests still > > pass (though I'm breaking the self-imposed encapsulation in quite a few > > places in order to get it to compile). > > > > The code is currently jointly owned by me and Red Hat; I'm sure we can > > do copyright assignment if/when it comes to that. > > > > You can see the work-in-progress in the "proposed-plugin-api" branch of > > gcc-python-plugin. > > > > For example, the proposed public header file looks like this: > > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/gcc-cfg.h;h=8dbeed0a6c5eb14b0336e89493746887c3bec20a;hb=36a0d6a45473c39db550915f8419a794f2f5653e > > > > For example, some design notes can be seen at: > > http://git.fedorahosted.org/git/?p=gcc-python-plugin.git;a=blob;f=proposed-plugin-api/design.rst;h=31b960ccac2dcf4d007701b5e9c6556e68e0d107;hb=36a0d6a45473c39db550915f8419a794f2f5653e > > > > How do other plugin authors feel about the API? > > Of course I don't like the CamelCasing ;) Seems like I'm the only person who does around here :) > The important part of the API is that it exposes no data structures and > all object references we expose are opaque. Right. There's a slight leak in gcc-semiprivate-types.h, but it's all clearly marked as private (I've seen information hiding where the inner pointers are all (void*) which sucks when you have to try and debug the resulting code: it's bad if the information-hiding approach manages to also hide things from the debugger!) > You have mostly wrapped in an iterator-style way, I suppose that's fine. > That (and the CamelCasing) exposes that using a different language for > this API would be desired; use namespaces to avoid CamelCasing and > STL style iterators / functors for the rest. If you stay with C rather > than using callbacks I would use an explicit iterator representation, > similar to how we have that now with gimple_stmt_iterator. Of course > that's personal preference, subject to bikeshedding. That raises fun issues like: can the thing be changed during an iteration? > Would the python plugin have any issue with using C++? I have a dislike for it, and will involve a little extra coding, but if C++ is what it will take to get me a stable API that I can code to (ideally with some kind of ABI guarantee), that seems a price worth paying. I don't know how other plugin authors feel (and I'm keen on hearing if they think my proposed API could work for them - modulo CamelCase, of course!). It's also possible to create a C wrapping around a C++ API and all kinds of other shenanigans (my Python code is already a wrapper around a wrapper, so yay, another level of indirection...) > > How do GCC subsystem maintainers feel? > > Well, positive! Thanks for starting. CFG introspection is indeed one > of the most important parts, then callgraph and statement introspection. > > > I initially attempted an underscore_based_naming_convention but quickly > > found it difficult to get concise function names, so I switched to a > > CamelCaseBased_NamingConvention with an underscore separating a notional > > namespace element from a secondary element, which saved plenty of space. > > The different naming convention also serves to highlight that this is > > *not* part of GCC's internals. > > > > Hope this is constructive > > Indeed, and thank you for that. > > Btw, how ugly is it to make this API grokable by swig? Would that serve > the python plugin? Why SWIG btw? I happen to have an intense loathing of SWIG (sorry SWIG maintainers): in my experience it gives ugly APIs that suffer from memory leaks, and you end up having to do pointer management in Python, without the typesafety that a C compiler would give you. FWIW, Cython is my wrapper-generator tool of choice, though that's for Python only. I may be biased, of course!. Would it be better to work from a higher-level representation of the API (e.g. XML, or some microformat?) and autogenerate the headers and source (and docs)? For the first iteration I wanted to keep things simple, hence I directly wrote code, rather than code-that-writes-code. Dave