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
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
Rather than invent a new quoting syntax, why not just split the
arguments up? If each a plugin has a name, you could use that name in
subsequent -f arguments. E.g., if the name of the plugin in
plugin.so is foo, perhaps:
-fplugin=/path/to/plugin.so -ffoo-arg1=value1 -ffoo-arg2=value2
The
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
interested in;
that way a plug-in would simply
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
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 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
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?
Sincerely,
Sean Callanan
Hal,
http://developer.apple.com/tools/download/
Sean
On Jun 19, 2008, at 2:13 PM, Hal Wigoda wrote:
i need to get the binaries for a c compiler for my mac.
where would i go?
you did to the [EMAIL PROTECTED]
mailing list. As a general rule, your Linux distribution version
should not matter for this.
Sincerely,
Sean Callanan
On Jun 19, 2008, at 7:40 PM, Sophia Han wrote:
Hi,
It seems that GCC 4.3.1 does not like the SuSE 10. 2v. It failed
when I
install GCC
;
}
rtx decl_rtl = assign_stack_local(DECL_MODE(ret), decl_size, 0);
SET_DECL_RTL(ret, decl_rtl);
return ret;
}
--
Sincerely,
Sean Callanan
On Jun 13, 2008, at 1:57 AM, Sean Callanan wrote:
Dear mailing list:
I am writing GCC code that constructs GIMPLE (after
pass_apply_inline
reference to `last_p.2610'
--
Oddly, I don't get undefined references for `last_p'; I find it very
odd that it's being renamed. Does anyone know what's going on here?
As always, I welcome corrections to my (admittedly novice-level)
GIMPLE- and SSA-fu.
Thanks for looking at this.
Sincerely,
Sean
, left_hand_side, address);
bsi_insert_before(iter, assignment, BSI_SAME_STMT);
}
return pointer_array;
}
--
Thanks very much for your time!
Sincerely,
Sean Callanan
to require something more than
PROP_gimple_any | PROP_ssa | PROP_cfg | PROP_referenced_vars, or is
there something else going on here?
Sincerely,
Sean Callanan
/tree-cfg.c:4684
#6 0x000100591ea8 in duplicate_block (bb=0x7eafbe10,
e=0x0) at ../../gcc-4.0.1/gcc/cfghooks.c:717
...
--
The context is a tree optimization pass, with PROP_gimple_any |
PROP_ssa | PROP_cfg | PROP_referenced_vars required.
Sincerely,
Sean Callanan
In short, you are proposing that instead of linking an executable, it
be made into a bunch of shared libraries. The function calls between
these shared libraries be arbitrated by a dispatcher which can
dynamically reroute function calls.
There already exists a technique to do this if
17 matches
Mail list logo
