C++ Plugins
(Version 4.5.0) There are plugin callbacks which trigger at the end of processing types and C++ functions, but I can not find a clean way for plugin code to notice a top-level variable declaration. I'm hoping that the answer does not require the plugin shared library to bind to global symbols of the compiler (i.e. global_namespace). TIA - Terrence Miller
Re: C++ Plugins
Benjamin Smedberg wrote: On 10/11/09 12:13 PM, Terrence Miller wrote: (Version 4.5.0) There are plugin callbacks which trigger at the end of processing types and C++ functions, but I can not find a clean way for plugin code to notice a top-level variable declaration. I'm hoping that the answer does not require the plugin shared library to bind to global symbols of the compiler (i.e. global_namespace). Why not? That's what dehydra does: it enumerates through the items in global_namespace in PLUGIN_FINISH_UNIT. --BDS Because it makes the name "global_namespace" and the list order(TREE_CHAIN (t) points to a declaration located earlier in the file than t) be part of the plugin interface and these two items are not documented. Also you end up with one way of handling top-level types (PLUGIN_FINISH_TYPE) and functions (PLUGIN_CXX_CP_PRE_GENERICIZE) and a different way of handling variables. A better scheme (IMO) would be to have a plugin triggered when the declaration of a variable is complete and another pair of plugins for scope entry/exit. Terrence
[Re: new plugin events]
< Forwarded due to missing address>
Original Message
Subject:Re: new plugin events
Date: Sun, 08 Nov 2009 18:25:21 +0100
From: Basile STARYNKEVITCH
To: Terrence Miller
References: <4ae72a4f.8000...@starynkevitch.net>
<4af28075.7020...@starynkevitch.net>
<4af291a6.7000...@starynkevitch.net>
<38a0d8450911050824l838fd92ya9f3a08205c80...@mail.gmail.com>
<4af33453.7090...@starynkevitch.net>
<38a0d8450911060724h3c6f9ddh3e84c2c763ac4...@mail.gmail.com>
<84fc9c000911060818s3462aff1r1ebfb298506b6...@mail.gmail.com>
<4af4634d.5050...@starynkevitch.net>
<4af47257.8040...@starynkevitch.net> <4af6fb88.4030...@sbcglobal.net>
Terrence Miller wrote:
I think this debate is missing one important issue. In order to generate
a patch to GCC
you have to know a lot more about the compiler internals than is
required to create
a plugin. I am doing some casual experimentation with compiler based
source browsing
and would love to have the DECL event(described below) added to the
plugin API.
I would prefer to not have to figure where that plugin should be called.
It is perhaps true for the DECL event you are talking about (which I did not understood fully), but I won't say that
coding a plugin is *in general* easier than proposing a patch to core GCC.
My perception is that most *middle* end plugins are working on Gimple and other middle-end representations. Usually,
they do that by adding a pass in the pass machinery. And knowing what pass to add (or replace) is as difficult when
coding a plugin than when coding a patch to GCC core.
Conversely, I would suspect than many previous patches (which have now bee incorporated in GCC core) could have if a
plugin machinery have been available at their time (which is false since plugin facilities is just coming in 4.5 which
has not yet been released), first been developped as plugins -at least to experiment their viability & interest- and
later one proposed as a patch.
This is why I believe that plugins will probably -at least for middle-end processing- have also the role of GCC branches
today, with a very important difference. Almost nobody compiles branches today (in the general GCC user community - I am
not talking of the smaller GCC developper community), and it could be the case that some plugins will be used.
For example, as far as I know, no common Linux distribution provides a package for any kind of GCC branch. I believe
(perhaps I am too optimistic) that some Linux distributions will package some few GCC plugins.
Apparently you did not sent your reply to gcc@; feel free to forward this (or
any reply to gcc@ if you want).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: [Re: new plugin events]
IDE projects are an example of development that could make good use of a
plugin that might never be integrated in the
compiler, indeed shouldn't ever be integrated in the compiler.
Terrence Miller
Richard Guenther wrote:
Basile STARYNKEVITCH wrote:
Terrence Miller wrote:
I think this debate is missing one important issue. In order to generate a
patch to GCC
you have to know a lot more about the compiler internals than is required
to create
a plugin. I am doing some casual experimentation with compiler based
source browsing
and would love to have the DECL event(described below) added to the plugin
API.
I would prefer to not have to figure where that plugin should be called.
It is perhaps true for the DECL event you are talking about (which I did not
understood fully), but I won't say that coding a plugin is *in general*
easier than proposing a patch to core GCC.
My perception is that most *middle* end plugins are working on Gimple and
other middle-end representations. Usually, they do that by adding a pass in
the pass machinery. And knowing what pass to add (or replace) is as
difficult when coding a plugin than when coding a patch to GCC core.
Conversely, I would suspect than many previous patches (which have now bee
incorporated in GCC core) could have if a plugin machinery have been
available at their time (which is false since plugin facilities is just
coming in 4.5 which has not yet been released), first been developped as
plugins -at least to experiment their viability & interest- and later one
proposed as a patch.
This is why I believe that plugins will probably -at least for middle-end
processing- have also the role of GCC branches today, with a very important
difference. Almost nobody compiles branches today (in the general GCC user
community - I am not talking of the smaller GCC developper community), and
it could be the case that some plugins will be used.
For example, as far as I know, no common Linux distribution provides a
package for any kind of GCC branch. I believe (perhaps I am too optimistic)
that some Linux distributions will package some few GCC plugins.
You keep re-iterating this (IMHO bogus) argument. I don't see how a plugin
in development is any different here - nobody will build or distribute it.
OTOH after a branch is mature it will be merged into the GCC core, so it
will be immediately available in distributed GCCs.
Richard.
Re: [Bulk] Re: Edit-and-continue
If you are willing to restrict edit-and-continue to whole procedures then minimal changes to the compiled code for procedure entry points is all that is required (well that and dlopen). Terrence MIller On 7/18/2010 12:14 PM, Dave Korn wrote: On 18/07/2010 16:28, Robert Dewar wrote: Rick Hodgin wrote: Ian, The idea is to create a program database of the compiled program on a full compile. Then when asked to re-compile with the edit-and-continue switch, it only looks for changed code and compiles those few lines. Everything else it needs to carry out compilation is there from previous full-compile as was originally parsed, or from subsequent edit-and-continue compiles which updated the database. Unlikely to be feasible in my view without slowing down compilation substantially. I think you're probably assuming too much. Tom T. is working on an incremental compiler, isn't he? I expect that that and LTO between them would / could give us all the tools we needed to make an EAC-friendly compiler. But yes, OP, it's a long-term project. cheers, DaveK
Re: [Bulk] Re: [Bulk] Re: Edit-and-continue
Rick, You are seeking perfection while I am suggesting a technique that doesn't capture all cases but is useful: 1) change only the body of a function 2) compile the new function into a shared library which the debugger dlopen's into the target process. 3) replace the entry-point code of the old function with a branch to the new version. On 7/18/2010 12:52 PM, Rick C. Hodgin wrote: Terrence, Procedure entry points, global and local variable locations in memory, structure definitions and offsets, etc. These would all have to be updated as changes are made, and that means each reference used in the executable would need to be updated, and that could mean several source files are recompiled with a single change which affects it. And if there are shared resources loaded, each of those would have to be updated as well, that is if we wanted to go "whole hog" like that. Otherwise, we could limit the changes to only the currently-executing program. The idea of having function entry points across the board for all executed code would be required, allowing those links to be updated dynamically at run-time. We could even use a memory-based lookup table that's updated by gdb to the new entry points for the executable code. It would be slower for execution, but for development the time savings would be there because changes could be made on the fly, recompiled, memory variables changed as needed, and then continue execution without restarting the entire app. The ability would also have to be created to allow local variable re-mapping across these updates, so that if the stack changed, the data on the stack is migrated from its old locations to the new ones. This would be a table built by gcc that's passed to gdb for each function, where gdb updates the stack in that way. If parent functions on the call stack were updated, they would have to be altered on the stack as well. This could be accommodated by automatically including a specified amount of "extra space" in local variable space per function entry point, something like 32 bytes (eight 4-byte variables) by default, with a compiler switch to increase that block size. This extra space would allow for a certain number of new variables before a full recompile is required again. We could also have #pragma-like statements for individual functions where we know some heavy changes will be used, to give them an extra 512 bytes, or whatever's specified. - Rick C. Hodgin On Sun, 2010-07-18 at 12:36 -0700, Terrence Miller wrote: If you are willing to restrict edit-and-continue to whole procedures then minimal changes to the compiled code for procedure entry points is all that is required (well that and dlopen). Terrence MIller On 7/18/2010 12:14 PM, Dave Korn wrote: On 18/07/2010 16:28, Robert Dewar wrote: Rick Hodgin wrote: Ian, The idea is to create a program database of the compiled program on a full compile. Then when asked to re-compile with the edit-and-continue switch, it only looks for changed code and compiles those few lines. Everything else it needs to carry out compilation is there from previous full-compile as was originally parsed, or from subsequent edit-and-continue compiles which updated the database. Unlikely to be feasible in my view without slowing down compilation substantially. I think you're probably assuming too much. Tom T. is working on an incremental compiler, isn't he? I expect that that and LTO between them would / could give us all the tools we needed to make an EAC-friendly compiler. But yes, OP, it's a long-term project. cheers, DaveK
