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
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
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
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 being
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
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 plugin
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston b...@au1.ibm.com 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!)
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
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
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 course,
On Sun, Feb 1, 2009 at 04:06, Sean Callanan spy...@cs.sunysb.edu 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
-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
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
2009/2/2 Sean Callanan spy...@cs.sunysb.edu:
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
On Mon, Feb 2, 2009 at 19:34, Taras Glek tg...@mozilla.com 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
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
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 should
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 macros /
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
22 matches
Mail list logo
