About -fstack-protector in mips
Hello I would like to use -fstack-protector in mips. But mips stack protector seems not to be supported. I think that the macro FRAME_GROWS_DOWNWARD should be defined for stack protector working. And mips does'nt define this macro. To define this macro, the addresses of local variable slots are at negative offsets from the frame pointer. (This info is from gccint.pdf) Although mips cpu seems to meet this requirement, just defining this macro doesn't makes "stack-protector" work certainly on mips. (This definition makes lots of testsuite fail on mips...) Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD on mips ? Thank you. --- Yoriko Komatsuzaki (yor...@sm.sony.co.jp)
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
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 framework will require special consideration for utilities like ccache and distcc. ccache checksums (or at least stats) the cc1 binary to decide whether a cached object file is valid. If you change a plugin, the cc1 binary won't change, but the generated code probably will. Ben
Re: ARM compiler generating never-used constant data structures
On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi wrote: [cut] > > If I compile the above with -O2 or -Os, then if the target is AVR or > x86_64 then the result is what I expected, func() just loads 3 or 12345 > then returns and that's all. There is no .rodata generated. > > However, compiling for the ARM generates the same function code, but it > also generates the image of "things" in the .rodata segment. Twice. Even > when it stores 12345 separatelly. The code never actually references > any of them and they are not global thus it is just wasted memory: > I think it's relevant to ask this: Are you comparing against the same gcc release on all the three architectures you mention?
Re: ARM compiler generating never-used constant data structures
On Thu, 5 Feb 2009 10:58:40 -0200 Alexandre Pereira Nunes wrote: > On Wed, Feb 4, 2009 at 11:05 PM, Zoltán Kócsi > wrote: [cut] > > > > If I compile the above with -O2 or -Os, then if the target is AVR or > > x86_64 then the result is what I expected, func() just loads 3 or > > 12345 then returns and that's all. There is no .rodata generated. > > > > However, compiling for the ARM generates the same function code, > > but it also generates the image of "things" in the .rodata segment. > > Twice. Even when it stores 12345 separatelly. The code never > > actually references any of them and they are not global thus it is > > just wasted memory: > > > > I think it's relevant to ask this: Are you comparing against the same > gcc release on all the three architectures you mention? Almost the same: x86_64: 4.0.2 AVR:4.0.1 ARM:4.0.2 So, at least the Intel and the ARM are the same yet the Intel version omits the .rodata, the ARM keeps it. I'll check it with the newer version next week. However, I tend to use the 4.0.x because at least for the ARM it generates smaller code from the same source than the newer versions when optimising with -Os. Zoltan
Re: Inline limits
> For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > to zero. Inlining at -Os should already only happen if it decreases > (overall!) code-size. Thus, inlining a function that is called once and > that does not need to be emitted will always be an overall code-size > win. > > > A side question... Are 'static' single call-site functions always > > inlined? I would hope not (under -Os), but just checking. > > Yes. This is always a code-size win. Should be, but in practice isn't. On Thumb-2 we found that the overhead of a function call was often smaller than the cost of lengthening branches in the caller. It turns out that, over a fair selection of applications, programmers tend to write "nice" sized functions. After inlining we have big nasty blocks of code that exceed the range of a short branch instruction. Of course a sufficiently smart reordering pass should be able to fix this by out-of-lining the big block of code. I'm pretty sure gcc can't currently do this. Paul
Re: Inline limits
On Thu, 5 Feb 2009, Paul Brook wrote: > > For -Os it should be enough to set PARAM_STACK_FRAME_GROWTH > > to zero. Inlining at -Os should already only happen if it decreases > > (overall!) code-size. Thus, inlining a function that is called once and > > that does not need to be emitted will always be an overall code-size > > win. > > > > > A side question... Are 'static' single call-site functions always > > > inlined? I would hope not (under -Os), but just checking. > > > > Yes. This is always a code-size win. > > Should be, but in practice isn't. > > On Thumb-2 we found that the overhead of a function call was often smaller > than the cost of lengthening branches in the caller. > It turns out that, over a fair selection of applications, programmers tend to > write "nice" sized functions. After inlining we have big nasty blocks of code > that exceed the range of a short branch instruction. > > Of course a sufficiently smart reordering pass should be able to fix this by > out-of-lining the big block of code. I'm pretty sure gcc can't currently do > this. Hmm, we should be able to model this counting the number of edges bypassing the call, right? Richard.
Re: Inline limits
> > On Thumb-2 we found that the overhead of a function call was often > > smaller than the cost of lengthening branches in the caller. > > It turns out that, over a fair selection of applications, programmers > > tend to write "nice" sized functions. After inlining we have big nasty > > blocks of code that exceed the range of a short branch instruction. > > > > Of course a sufficiently smart reordering pass should be able to fix this > > by out-of-lining the big block of code. I'm pretty sure gcc can't > > currently do this. > > Hmm, we should be able to model this counting the number of edges > bypassing the call, right? Something like that, yes. Ideally you'd want to factor in the size of the function, and the current length of those edges, at which point you've probably got sufficient information to make bb-reorder fix the problem once and for all ;-) Paul
Re: Inline limits
On Thu, Feb 5, 2009 at 3:04 PM, Paul Brook wrote: >> Hmm, we should be able to model this counting the number of edges >> bypassing the call, right? > > Something like that, yes. > > Ideally you'd want to factor in the size of the function, and the current > length of those edges, at which point you've probably got sufficient > information to make bb-reorder fix the problem once and for all ;-) I haven't read the thread in full, so maybe someone already mentioned it... You do know bb-reorder is completely disabled for -Os, right? Gr. Steven
Re: ARM compiler generating never-used constant data structures
On Fri, Feb 06, 2009 at 12:30:13AM +1100, Zoltán Kócsi wrote: > Almost the same: > > x86_64: 4.0.2 > AVR:4.0.1 > ARM:4.0.2 > > So, at least the Intel and the ARM are the same yet the Intel version > omits the .rodata, the ARM keeps it. I'll check it with the newer > version next week. However, I tend to use the 4.0.x because at least for > the ARM it generates smaller code from the same source than the newer > versions when optimising with -Os. Still, there's not much help people can give you with old versions. If you have any test cases where 4.0.2 gives smaller code with -Os than a 4.4 snapshot, please, file them in bugzilla. -- Daniel Jacobowitz CodeSourcery
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
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 releases. > > Thinking about this made me realise that the plugin framework will > require special consideration for utilities like ccache and distcc. > ccache checksums (or at least stats) the cc1 binary to decide whether a > cached object file is valid. If you change a plugin, the cc1 binary > won't change, but the generated code probably will. Why not use the output of cc1 --version, and then have the loaded plugins listed there. (This also means bug reports should have the plugins listed assuming the user uses the same command line with --version tacked on)
Re: About -fstack-protector in mips
Yoriko Komatsuzaki writes:
> Could you tell me why it doesn't work well around FRAME_GROWS_DOWNWARD
> on mips ?
I have a WIP patch for this but was holding back mostly because of stage3/4
and that I was trying to make FRAME_GROWS_DOWNWARD the default and I was
running into performance issues.
The patch below enables FRAME_GROWS_DOWNWARD with -mframe-grows-downward
(mostly for testing) and with -fstack-protector.
Adam
Index: config/mips/mips.opt
===
--- config/mips/mips.opt(revision 142249)
+++ config/mips/mips.opt(working copy)
@@ -283,3 +283,6 @@ Perform VR4130-specific alignment optimi
mxgot
Target Report Var(TARGET_XGOT)
Lift restrictions on GOT size
+
+mframe-grows-downward
+Target Var(flag_frame_grows_downward) Init(1)
Index: config/mips/mips.c
===
--- config/mips/mips.c (revision 142249)
+++ config/mips/mips.c (working copy)
@@ -274,10 +274,10 @@ struct mips_frame_info GTY(()) {
HOST_WIDE_INT gp_sp_offset;
HOST_WIDE_INT fp_sp_offset;
- /* The offset of arg_pointer_rtx from frame_pointer_rtx. */
+ /* The offset of arg_pointer_rtx from the bottom of the frame. */
HOST_WIDE_INT arg_pointer_offset;
- /* The offset of hard_frame_pointer_rtx from frame_pointer_rtx. */
+ /* The offset of hard_frame_pointer_rtx from the bottom of the frame. */
HOST_WIDE_INT hard_frame_pointer_offset;
};
@@ -8593,10 +8593,9 @@ mips_compute_frame_info (void)
cfun->machine->global_pointer = mips_global_pointer ();
- /* The first STARTING_FRAME_OFFSET bytes contain the outgoing argument
- area and the $gp save slot. This area isn't needed in leaf functions,
- but if the target-independent frame size is nonzero, we're committed
- to allocating it anyway. */
+ /* The first bytes contain the outgoing argument area and the $gp save slot.
+ This area isn't needed in leaf functions, but if the target-independent
+ frame size is nonzero, we're committed to allocating it anyway. */
if (size == 0 && current_function_is_leaf)
{
/* The MIPS 3.0 linker does not like functions that dynamically
@@ -8612,7 +8611,7 @@ mips_compute_frame_info (void)
else
{
frame->args_size = crtl->outgoing_args_size;
- frame->cprestore_size = STARTING_FRAME_OFFSET - frame->args_size;
+ frame->cprestore_size = MIPS_GP_SAVE_AREA_SIZE;
}
offset = frame->args_size + frame->cprestore_size;
@@ -8746,12 +8745,16 @@ mips_initial_elimination_offset (int fro
mips_compute_frame_info ();
- /* Set OFFSET to the offset from the soft frame pointer, which is also
- the offset from the end-of-prologue stack pointer. */
+ /* Set OFFSET to the offset from the end-of-prologue stack pointer. */
switch (from)
{
case FRAME_POINTER_REGNUM:
- offset = 0;
+ if (FRAME_GROWS_DOWNWARD)
+ offset = (cfun->machine->frame.args_size
+ + cfun->machine->frame.cprestore_size
+ + cfun->machine->frame.var_size);
+ else
+ offset = 0;
break;
case ARG_POINTER_REGNUM:
Index: config/mips/mips.h
===
--- config/mips/mips.h (revision 142249)
+++ config/mips/mips.h (working copy)
@@ -2035,14 +2035,20 @@ enum reg_class
/* Stack layout; function entry, exit and calling. */
+#define FRAME_GROWS_DOWNWARD (flag_frame_grows_downward || flag_stack_protect)
+
#define STACK_GROWS_DOWNWARD
-/* The offset of the first local variable from the beginning of the frame.
- See mips_compute_frame_info for details about the frame layout. */
+#define MIPS_GP_SAVE_AREA_SIZE \
+ (TARGET_CALL_CLOBBERED_GP ? MIPS_STACK_ALIGN (UNITS_PER_WORD) : 0)
+
+/* The offset of the first local variable from the frame pointer. See
+ mips_compute_frame_info for details about the frame layout. */
-#define STARTING_FRAME_OFFSET \
- (crtl->outgoing_args_size\
- + (TARGET_CALL_CLOBBERED_GP ? MIPS_STACK_ALIGN (UNITS_PER_WORD) : 0))
+#define STARTING_FRAME_OFFSET \
+ (FRAME_GROWS_DOWNWARD\
+ ? 0 \
+ : crtl->outgoing_args_size + MIPS_GP_SAVE_AREA_SIZE)
#define RETURN_ADDR_RTX mips_return_addr
Re: GCC for mipsel-unknown-linux-gnu state on 4.3 and 4.4?
On Sun, 2009-02-01 at 22:45 +0100, Laurent GUERBY wrote: > Thanks for the link! > > This confirms that all pch test fail on mipsel, from the first > to the last log available on your site: > > http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20080523-1_mipsel.bz2 > http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20090107-1_mipsel.bz2 > > FAIL: ./common-1.h -O0 -g (test for excess errors) > FAIL: gcc.dg/pch/common-1.c -O0 -g > FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison > FAIL: ./common-1.h -O0 (test for excess errors) > FAIL: gcc.dg/pch/common-1.c -O0 > FAIL: gcc.dg/pch/common-1.c -O0 assembly comparison > ... > > Whereas they don't fail for 4.3. > > I opened: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39071 I just closed it, something between 143818 and 143942 fixed it: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00541.html I assume this will show up on your build soon. Laurent
Constant folding and Constant propagation
Dear all, I'm currently working on removing the constant folding and constant propagation because, on the architecture I'm working on, it is highly costly to move a constant into a register if the number is big (we can say over 16 bits). Currently, I've been looking into this and it seems that I have to hack into the fold-const.c file, CCP, SCCVN and probably the propagate passes to tell the compiler to be careful if the number is too big. But I'm sure there are many other places I'll have to hack and slash to tell him to stop the folding and propagation. Is there an easier way to do this ? I've been looking at what happens for the Itanium since you'd have the same problem if you had to use big numbers. You would in theory prefer to not use too many move long instructions since they use two slots in the bundle. But I fail to see if anything is really done in that respect. Thanks for your help, Jean Christophe Beyler
Re: Constant folding and Constant propagation
On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote: > I'm currently working on removing the constant folding and constant > propagation because, on the architecture I'm working on, it is highly > costly to move a constant into a register if the number is big (we can > say over 16 bits). But in practice most constants that cprop deals with are values like -1, 0, 1, or 2. Wouldn't it be better to be able to constrain cprop based on the values of the constants, than to eliminate it altogether?
Re: Constant folding and Constant propagation
On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote: > On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote: > > I'm currently working on removing the constant folding and constant > > propagation because, on the architecture I'm working on, it is highly > > costly to move a constant into a register if the number is big (we can > > say over 16 bits). > > But in practice most constants that cprop deals with are values like > -1, 0, 1, or 2. Wouldn't it be better to be able to constrain cprop > based on the values of the constants, than to eliminate it altogether? I shouldn't have said "most", but small constants are common.
Re: Constant folding and Constant propagation
True but what I've noticed with GCC 4.3.2 is that with this code:
#include
#include
int main(void)
{
long a = 0xcafecafe;
printf("Final: %lx %lx %lx\n", a, a+5, a+15);
return EXIT_SUCCESS;
}
Whether I compile it with a big number like here or a smaller number,
I'll get something like:
la r8,$LC0 #Loading the address of
"Final: %lx %lx %lx\n"
lid r9,0xcafecafe#Loading the first immediate
lid r10,0xcafecb03 #Loading the second immediate
lid r11,0xcafecb0d #Loading the third immediate
But in my case, the lid is very costly for this large number. It would
be more efficient to have:
la r8,$LC0 #Loading the address of
"Final: %lx %lx %lx\n"
lid r9,0xcafecafe#Loading the first immediate
addi r10,r9,0x5 #Loading the second immediate
addi r11,r9,0xf #Loading the third immediate
So my question is, can I explain this in the machine description alone
and if so, does anybody know where?
Thanks again,
Jean Christophe Beyler
On Thu, Feb 5, 2009 at 4:02 PM, Joe Buck wrote:
> On Thu, Feb 05, 2009 at 12:46:01PM -0800, Joe Buck wrote:
>> On Thu, Feb 05, 2009 at 12:34:14PM -0800, Jean Christophe Beyler wrote:
>> > I'm currently working on removing the constant folding and constant
>> > propagation because, on the architecture I'm working on, it is highly
>> > costly to move a constant into a register if the number is big (we can
>> > say over 16 bits).
>>
>> But in practice most constants that cprop deals with are values like
>> -1, 0, 1, or 2. Wouldn't it be better to be able to constrain cprop
>> based on the values of the constants, than to eliminate it altogether?
>
> I shouldn't have said "most", but small constants are common.
>
>
Re: Constant folding and Constant propagation
Jean Christophe Beyler writes: > I'm currently working on removing the constant folding and constant > propagation because, on the architecture I'm working on, it is highly > costly to move a constant into a register if the number is big (we can > say over 16 bits). > > Currently, I've been looking into this and it seems that I have to > hack into the fold-const.c file, CCP, SCCVN and probably the propagate > passes to tell the compiler to be careful if the number is too big. > But I'm sure there are many other places I'll have to hack and slash > to tell him to stop the folding and propagation. Is there an easier > way to do this ? This type of thing is normally controlled by the TARGET_RTX_COSTS hook. E.g., see the handling of CONST_INT mips_rtx_costs in config/mips/mips.c. Ian
gcc-4.3-20090205 is now available
Snapshot gcc-4.3-20090205 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090205/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 143973 You'll find: gcc-4.3-20090205.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090205.tar.bz2 C front end and core compiler gcc-ada-4.3-20090205.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090205.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090205.tar.bz2 C++ front end and runtime gcc-java-4.3-20090205.tar.bz2 Java front end and runtime gcc-objc-4.3-20090205.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090205.tar.bz2The GCC testsuite Diffs from 4.3-20090129 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
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 old wiki. (I can send out
the patch later for people's reference.) The updated APIs in general
look good to me. I do have some comments based on our experience with
the initial prototyping:
Neat! I'd love to see that.
void register_callbacks(int nregistrations, struct plugin_registration
*registrations);
Instead of passing in an array of plugin_registration objects with a
single register_callbacks call, it's probably better to have the
plugin call a sequence of register_callback with the necessary
information, as shown in the following example:
void plugin_register_callback (const char *plugin_name, enum
plugin_event event, plugin_callback_func callback, void *user_data);
/* In plugin code */
void
plugin_init()
{
...
register_callback (plugin_name, PLUGIN_FINISH_STRUCT, handle_struct, NULL);
register_callback (plugin_name, PLUGIN_FINISH_UNIT,
handle_end_of_compilation_unit, NULL);
...
}
In the function body of register_callback, GCC can then create the
plugin_registration objects and chain them together based on the event
type. Because GCC will need to maintain a list of plugin_registration
objects for each event anyway, we might as well let it create (and
destroy if necessary) the objects instead of leaving the task to the
plugins.
Note that in my example an additional parameter, plugin_name, is added
in register_callback. We found it useful to have the name around when
emitting error messages if something goes wrong during the callback
registration process.
Sean,
I agree with Le-Chun that separate register_callback calls would be
better. Would you change that(in the interest of not having too many
people modify the api), or should I? By the way, reformatting made the
page much more readable, thanks.
I think having a plugin-name parameter is something we can decide on
later ( just like the version stuff). I can see it being useful for
debugging a situation with multiple loaded plugins, but I'm not
convinced that it will be a common problem.
-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, can be something like
"arg1=value arg2=value") and pass it (unparsed) to the plugin. It is
plugin's job to parse/process the given arguments (whatever way it
likes). So the prototype of the plugin_init would look like this:
void plugin_init (const char *plugin_name, const char *plugin_arg);
In our current prototype, we implemented the originally proposed flag
"-fplugin-arg=", which is associated with the plugin specified in the
most recently parsed "-fplugin" flag. If a "-fplugin-arg" flag is used
in the command-line without any preceding "-fplugin", an error message
is emitted. Having the plugin name and its arguments concatenated as
currently proposed is also fine, but I would prefer a simple string
(like below) to a series of key-value pairs.
-fplugin=/path/to/plugin.so;"arguments"
(Note that the double quotes may not needed if the "arguments" doesn't
contain characters such as spaces.)
I agree with Daniel Jacobowitz's comment that letting every plugin to
parse command-lines will lead to insanity. I'd be nice to let GCC take
care of as much as possible there.
From my brief encounter with the complexity of parameter handling code
in GCC I would be tempted to start with the simplest possible proposal:
either use -fplugin-arg as I described or stuffing everything into
-fplugin and using a semi-colon separator.
Infact, I would prefer not using -fplugin-arg as that leaves more room
for future implementations to use -fplugin-- to do
plugin arguments.
Pass Manager
We think it would be quite daunting (and probably open up a can of
worms) to allow plugins to re-order passes. So to get things moving
quickly, in our initial prototype we only support insertion of a new
pass and replacing an existing pass. When registering a new pass with
GCC, the plugin uses the normal register_callback call with the
PLUGIN_PASS_MANAGER_SETUP event. However, instead of registering a
callback function, it passes in a plugin_pass object (see below) that
specifies the opt_pass object of the new pass, the name of the
reference pass, the static instance number of the reference pass, and
whether to insert before/after or replacing the reference pass.
enum pass_positioning_ops
{
PASS_POS_INSERT_AFTER,
PASS_POS_INSERT_BEFORE,
PASS_POS_REPLACE
};
struct plugin_pass
{
struct opt_pass *pass;
const char *reference_pass_name;
/* Insert the pass at the specified instance of the reference
Re: Plugin API Comments (was Re: GCC Plug-in Framework ready to port)
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 plugin support soon. I know we
still have some issues that have yet to converge (such as flags for
plugin arguments). But in order to get things moving, what do you
think if we start with this patch and move from there? Or if you have
other patches available that implement the currently proposed APIs,
we can start with those too. Thanks.
Le-chun
On Thu, Feb 5, 2009 at 3:27 PM, Taras Glek wrote:
> 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 old wiki. (I can send out
>> the patch later for people's reference.) The updated APIs in general
>> look good to me. I do have some comments based on our experience with
>> the initial prototyping:
>>
>
> Neat! I'd love to see that.
>>
>>
void register_callbacks(int nregistrations, struct plugin_registration
*registrations);
>>
>> Instead of passing in an array of plugin_registration objects with a
>> single register_callbacks call, it's probably better to have the
>> plugin call a sequence of register_callback with the necessary
>> information, as shown in the following example:
>>
>> void plugin_register_callback (const char *plugin_name, enum
>> plugin_event event, plugin_callback_func callback, void *user_data);
>>
>> /* In plugin code */
>> void
>> plugin_init()
>> {
>> ...
>> register_callback (plugin_name, PLUGIN_FINISH_STRUCT, handle_struct,
>> NULL);
>> register_callback (plugin_name, PLUGIN_FINISH_UNIT,
>> handle_end_of_compilation_unit, NULL);
>> ...
>> }
>>
>> In the function body of register_callback, GCC can then create the
>> plugin_registration objects and chain them together based on the event
>> type. Because GCC will need to maintain a list of plugin_registration
>> objects for each event anyway, we might as well let it create (and
>> destroy if necessary) the objects instead of leaving the task to the
>> plugins.
>>
>> Note that in my example an additional parameter, plugin_name, is added
>> in register_callback. We found it useful to have the name around when
>> emitting error messages if something goes wrong during the callback
>> registration process.
>>
>
> Sean,
> I agree with Le-Chun that separate register_callback calls would be better.
> Would you change that(in the interest of not having too many people modify
> the api), or should I? By the way, reformatting made the page much more
> readable, thanks.
>
> I think having a plugin-name parameter is something we can decide on later (
> just like the version stuff). I can see it being useful for debugging a
> situation with multiple loaded plugins, but I'm not convinced that it will
> be a common problem.
>
>>
-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, can be something like
>> "arg1=value arg2=value") and pass it (unparsed) to the plugin. It is
>> plugin's job to parse/process the given arguments (whatever way it
>> likes). So the prototype of the plugin_init would look like this:
>>
>> void plugin_init (const char *plugin_name, const char *plugin_arg);
>>
>> In our current prototype, we implemented the originally proposed flag
>> "-fplugin-arg=", which is associated with the plugin specified in the
>> most recently parsed "-fplugin" flag. If a "-fplugin-arg" flag is used
>> in the command-line without any preceding "-fplugin", an error message
>> is emitted. Having the plugin name and its arguments concatenated as
>> currently proposed is also fine, but I would prefer a simple string
>> (like below) to a series of key-value pairs.
>>
>> -fplugin=/path/to/plugin.so;"arguments"
>>
>> (Note that the double quotes may not needed if the "arguments" doesn't
>> contain characters such as spaces.)
>>
>
> I agree with Daniel Jacobowitz's comment that letting every plugin to parse
> command-lines will lead to insanity. I'd be nice to let GCC take care of as
> much as possible there.
>
> From my brief encounter with the complexity of parameter handling code in
> GCC I would be tempted to start with the simplest possible proposal: either
> use -fplugin-arg as I described or stuffing everything into -fplugin and
> using a semi-colon separator.
> Infact, I would prefer not using -fplugin-arg as that leaves more room for
> future implementations to use -fplugin-- to do plugin
> arguments.
>>
>>
