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.
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
-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
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
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.
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
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
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
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, 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
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 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
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
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 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
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 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
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
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
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
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
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
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
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
26 matches
Mail list logo
