This is the mail archive of the
mailing list for the GCC project.
Re: Proposed plugin API for GCC
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: David Malcolm <dmalcolm at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 30 Mar 2012 14:14:31 +0200
- Subject: Re: Proposed plugin API for GCC
- References: <1333054687.31165.65.camel@surprise>
On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm <firstname.lastname@example.org> wrote:
> I had a go at writing a possible plugin API for GCC, and porting parts
> of my python plugin to it:
> 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
> For example, the proposed public header file looks like this:
> For example, some design notes can be seen at:
> How do other plugin authors feel about the API?
Of course I don't like the CamelCasing ;)
The important part of the API is that it exposes no data structures and
all object references we expose are opaque.
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.
Would the python plugin have any issue with using C++?
> 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?