From: David Malcolm <dmalcolm@redhat.com>
To: Richard Guenther <richard.guenther@gmail.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Proposed plugin API for GCC
Date: Fri, 30 Mar 2012 23:17:00 -0000 [thread overview]
Message-ID: <1333149367.2447.29.camel@surprise> (raw)
In-Reply-To: <CAFiYyc35AGhXUV7Q8hff=uXxyusoBezt+E_+goZwgOe=Le3Zmg@mail.gmail.com>
On Fri, 2012-03-30 at 14:14 +0200, Richard Guenther wrote:
> On Thu, Mar 29, 2012 at 10:58 PM, David Malcolm <dmalcolm@redhat.com> 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
prev parent reply other threads:[~2012-03-30 23:17 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-29 20:59 David Malcolm
2012-03-30 0:06 ` Miles Bader
2012-03-30 22:55 ` David Malcolm
2012-03-30 4:18 ` Ian Lance Taylor
2012-03-30 8:47 ` Romain Geissler
2012-03-30 13:48 ` Ian Lance Taylor
2012-03-30 18:17 ` Romain Geissler
2012-03-30 8:23 ` Ludovic Courtès
2012-03-30 8:32 ` Richard Guenther
2012-03-30 9:45 ` Ludovic Courtès
2012-03-30 12:01 ` Gabriel Dos Reis
2012-03-30 13:55 ` Ludovic Courtès
2012-03-30 9:33 ` Basile Starynkevitch
2012-03-30 11:59 ` Gabriel Dos Reis
2012-03-30 11:55 ` Gabriel Dos Reis
2012-03-30 11:59 ` Richard Guenther
2012-03-30 12:04 ` Gabriel Dos Reis
2012-03-30 14:31 ` Ian Lance Taylor
2012-03-30 14:49 ` Ludovic Courtès
2012-03-30 15:13 ` Gabriel Dos Reis
2012-03-30 12:14 ` Richard Guenther
2012-03-30 13:09 ` Basile Starynkevitch
2012-03-31 0:46 ` David Malcolm
2012-03-31 1:44 ` Gabriel Dos Reis
2012-04-02 15:16 ` Michael Matz
2012-03-31 9:10 ` Romain Geissler
2012-03-30 23:17 ` David Malcolm [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1333149367.2447.29.camel@surprise \
--to=dmalcolm@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).