Our SVN tree is here:
svn co svn://gcc.gnu.org/svn/gcc/branches/plugin gcc
This is an old branch off the GCC 4.3 mainline that Eric Christopher
helped create after the 2007 GCC Summit, but we can update it if
necessary. It includes libtool and libltdl, which may be useful.
FWIW, the libto
Sean,
I don't really think most people are contributing to GCC for the
bragging rights (at least I am not :-)). I would consider this a
concerted, collaborating effort to get a simple, robust, and
accommodating plugin design and implementation out as quickly as
possible so that people can start us
On Fri, 2009-02-06 at 12:32 +, Joseph S. Myers wrote:
> On Fri, 6 Feb 2009, Sean Callanan wrote:
>
> > - Modify the GCC link process to use libltdl and libtool -export-dynamic
>
> Although this may make theoretical sense in terms of the work for a
> cross-platform implementation already bein
On Fri, 6 Feb 2009, Sean Callanan wrote:
> - Modify the GCC link process to use libltdl and libtool -export-dynamic
Although this may make theoretical sense in terms of the work for a
cross-platform implementation already being done, I doubt it's a good idea
in practice if you want plugin-enabl
As a matter of protocol, I know there are several groups that all have
implementations. I bet any one of them would love to have the credit
of having their implementation be the one that got adopted. (I know
ours would! We're academics and would love to claim bragging rights.)
In practic
I have updated the API Wiki at http://gcc.gnu.org/wiki/GCC_PluginAPI.
1) The way to pass arguments to plug-ins has been reverted to the
approach suggested by many:
--
-fplugin=/path/to/NAME.so -fNAME-arg1=value -fNAME-arg2=value
--
2) The name of struct plugin_registration is now struct
c
Attached please find the patch of our initial prototype of GCC plugin
support based on the APIs described in the (old) wiki page. I also
attached a sample plugin program (dumb-example.c) that shows how a
plugin uses the APIs.
Sean and Taras (and others),
Diego will be creating a branch for the pl
Le-Chun Wu wrote:
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston wrote:
> On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
>
>> Our plugins do not break when switching compiler binaries. In fact, I
>> have had plug-in binaries that perform very simple tasks work fine
>> when switching (minor!) compiler releas
On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
> Our plugins do not break when switching compiler binaries. In fact, I
> have had plug-in binaries that perform very simple tasks work fine
> when switching (minor!) compiler releases.
Thinking about this made me realise that the plugi
2009/2/1 Sean Callanan :
>
> (3) The -fplugin-arg argument is one way to do arguments. We do it as
>
> -ftree-plugin=/path/to/plugin.so:arg=value:arg=value:...
>
In the previous discussions we had on this whole thing
(http://gcc.gnu.org/ml/gcc/2008-09/msg00292.html), we were aiming
towards argum
On Wed, Feb 04, 2009 at 05:04:10PM -0800, Le-Chun Wu wrote:
> >> -fplugin=/path/to/plugin.so;arg1=value;arg2=value;...
> >>
>
> I am not sure if it is GCC's responsibility to understand key-value
> (or any other types of) arguments to plugins. I think GCC should
> simply take a string (which, of c
Hi Sean,
It's great that you updated the wiki page with the latest and more
detailed API design.
We (at Google) also started to look at the GCC plugin support a couple
of weeks ago. We had a quick prototype implemented based on the
original APIs that Taras put together in the old wiki. (I can sen
On Sun, Feb 1, 2009 at 04:06, Sean Callanan wrote:
> We also have a magic argument called FILE that lets you load arguments from
> a file.
That's what @ arguments are for. Which argues for not concatenating arguments.
Would it be a problem to do
-plugin=myplugin -plugin-myplugin-arg1=stuff -pl
On Feb 2, 2009, at 9:15 PM, Mark Mitchell wrote:
Unless we have a lot more stability in plugin API than I expect we're
actually going to have at first, I suggest we check something like the
md5sum of the GCC binary itself. (Yes, I see the recursive problem in
building such a binary.) The chance
Joseph S. Myers wrote:
> I agree with checking once at startup, but that should be GCC's job, not
> the plugin's.
Yes.
> The plugin should export the exact version string and
> target triplet (and maybe configure options) of the compiler it was built
> to be plugged into (the configure macro
On Mon, 2 Feb 2009, Taras Glek wrote:
> Regarding versions: I think it's crazy to be passing a version in every single
> function call. The plugin should check the gcc version it is being loaded
> into on startup and bail if it doesn't match.
I agree with checking once at startup, but that shoul
Taras,
On Feb 2, 2009, at 7:34 PM, Taras Glek wrote:
Regarding versions: I think it's crazy to be passing a version in
every single function call. The plugin should check the gcc version
it is being loaded into on startup and bail if it doesn't match.
Since you and Diego seem to be of one m
On Mon, Feb 2, 2009 at 19:34, Taras Glek wrote:
> Regarding versions: I think it's crazy to be passing a version in every
> single function call. The plugin should check the gcc version it is being
> loaded into on startup and bail if it doesn't match.
Agreed. Let's start with simpler mechanis
Sean Callanan wrote:
Benjamin,
On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote:
It's possible for the plugin to implement every possible dlsym entry
point
and then farm the calls out to each individual script pass
internally, but
since GCC is already going to have to maintain a list of ca
Benjamin,
On Feb 2, 2009, at 2:15 PM, Benjamin Smedberg wrote:
It's possible for the plugin to implement every possible dlsym entry
point
and then farm the calls out to each individual script pass
internally, but
since GCC is already going to have to maintain a list of callbacks,
it seems
2009/2/2 Sean Callanan :
> I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI.
>
Is there a reason for not using just -plugin=? What is with the -f*?
Cheers,
Manuel.
I updated the page http://gcc.gnu.org/wiki/GCC_PluginAPI.
I cleaned up the formatting and added syntax coloring where
appropriate. I also changed the API to reflect the comments so far,
making it easier to register many callbacks at once while preserving
the ability to register callbacks d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/31/09 10:06 PM, Sean Callanan wrote:
> (1) register_callback is an unnecessary API. It's already possible to
> use dlsym() to get a pointer to a symbol in a plug-in. A plug-in could
> export a function symbol corresponding to each hook it is in
Sean Callanan wrote:
1- Agree on a common API and document it in
http://gcc.gnu.org/wiki/GCC_PluginAPI
So to get the ball rolling, here are some comments on the API as
documented:
-
(1) register_callback is an unnecessary API. It's already possible to
use dlsym() to get a pointer to a s
On Sun, 2009-02-01 at 14:26 -0500, Diego Novillo wrote:
> Yes, that's the path I was describing; plugins distributed with GCC.
> I don't expect we'll have more than a small number of them. Mostly as
> examples.
The usual problem with example plugins is that they stop working. It
would be nice i
On Sun, 1 Feb 2009, Diego Novillo wrote:
> > As for installation directories, I've already noted that plugins should be
> > installed under libsubdir or libexecsubdir since they will depend on both
> > the target and version of GCC.
>
> Agreed. We'll also need some convention for the API header
On Sun, Feb 1, 2009 at 13:50, Joseph S. Myers wrote:
> As plugin-centric enhancements as described seem to be changes to existing
> GCC source code (providing infrastructure of potential use to multiple
> plugins), they don't have a single plugin-name, so the path you gave
> doesn't make sense as
On Sun, 1 Feb 2009, Diego Novillo wrote:
> > Where would plugin-centric enhancements such as improvements to the pass
> > manager go? i think it'd be useful to have them land in the plugin branch to
> > make sure the API is satisfactory.
>
> How about /gcc/plugins/? Maybe we could categorize
> t
On Sat, Jan 31, 2009 at 17:49, Taras Glek wrote:
> Why not start the branch with the API as is described and then change it as
> people find problems with it. I am guessing we should converge on an API
> that the majority of users are happy with fairly quickly.
Yes, that's why I suggested using
1- Agree on a common API and document it in
http://gcc.gnu.org/wiki/GCC_PluginAPI
So to get the ball rolling, here are some comments on the API as
documented:
-
(1) register_callback is an unnecessary API. It's already possible to
use dlsym() to get a pointer to a symbol in a plug-in.
On Sat, 31 Jan 2009, Taras Glek wrote:
> One simple and useful plugin could be a per-function warning suppressor. ie
> functions flagged with user(no-warn-unused-variable) could suppress a
> particular false warning.
I don't really think it makes sense for this to be a plugin; it's generic
infra
On Sat, 31 Jan 2009, Diego Novillo wrote:
> 1- Agree on a common API and document it in
>http://gcc.gnu.org/wiki/GCC_PluginAPI
>
> 2- Create a new branch to implement that common API. The branch
>would *only* be for basic plugin functionality.
I also think it is strongly desirable that
Diego Novillo wrote:
On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
We've been off the ML for some time, but we're still out there.
Is this something that is wanted, or have we been overtaken
by events and should be porting to someone else's
implementation?
Thanks for raising th
Saturday, January 31, 2009 2:28 PM
> To: Richard Guenther
> Cc: Sean Callanan; Taras Glek; Basile STARYNKEVITCH; Grigori Fursin; Le-Chun
> Wu; Brendon
> Costa; Emmanuel Fleury; gcc@gcc.gnu.org
> Subject: Re: GCC Plug-in Framework ready to port
>
> On Sat, Jan 31, 2009 at 08
On Sat, Jan 31, 2009 at 08:24, Richard Guenther
wrote:
> On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo wrote:
>>
>> 1- Agree on a common API and document it in
>> http://gcc.gnu.org/wiki/GCC_PluginAPI
>
> Note that even for this taks being able to compare what the existing
> frameworks
> impl
On Sat, Jan 31, 2009 at 2:11 PM, Diego Novillo wrote:
> On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
>
>> We've been off the ML for some time, but we're still out there.
>> Is this something that is wanted, or have we been overtaken
>> by events and should be porting to someone else's
>> i
On Fri, Jan 30, 2009 at 23:01, Sean Callanan wrote:
> We've been off the ML for some time, but we're still out there.
> Is this something that is wanted, or have we been overtaken
> by events and should be porting to someone else's
> implementation?
Thanks for raising the issue. The last time w
On Sat, Jan 31, 2009 at 5:01 AM, Sean Callanan wrote:
> Dear mailing list:
>
> My research group (the High-Confidence Operating Systems group at Stony
> Brook University;
> home page http://www.fsl.cs.sunysb.edu/hcos/) continues to use a modified
> branch of
> Subversion GCC that hosts plug-ins wr
39 matches
Mail list logo
