This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new plugin events
On Fri, Nov 6, 2009 at 10:41 PM, Basile STARYNKEVITCH
<basile@starynkevitch.net> wrote:
> Richard Guenther wrote:
(stop reading now, what follows is pure cynicism - I have to do it, because
the following can't be let un-responded, rather than un-answered)
> Actually, I tend to believe that the plugin infrastructure should ideally
> permit to replace almost every single file in GCC by an equivalent file in
> the plugin. Take for example the pass manager (file gcc/passes.c) I
> understood that ICI have their own pass manager (By the way, I Basile don't
> care about the pass manager). So ICI guys would probably be happy to bypass
> all the functions in the gcc-4.5/gcc/passes.c and provide their own variant
> of these. My intuition is that this should be doable.
It should be possible already if you build GCC with -fPIC. You then
can LD_PRELOAD a plugin replacing all functions you want to replace.
Thanks to the wonders of ELF.
> I probably am happy enough with the current set of hooks. I might wish in a
> year some hooks for CPP, but I understood Diego need them, so I believe they
> will appear.
>
> But I am not sure that every GCC experiment is pluginable today (I really
> don't know). Take for instance all the papers in the recent GCC summits
> (let's say after 2007). All of them describe code related to GCC. I am not
> sure that every such code could fit as a plugin. I believe it should.
Ah, you mean like doing the tuples conversion as plugin? Or to
build the cgraph infrastructure and IPA optimization infrastructure
as plugin? I guess what you say is - "stop developing gcc! develop plugins!"?
> Perhaps all of GCC code is bypassable by a plugin which would handle
> PLUGIN_START_UNIT, copy or call all of the existing code of GCC inside it,
> and exit without returning... So probably, plugin could do anything.
What's the point? We have plugins for the kernel for this - it's called
programs, the plugin architecture is processes.
> But I believe we should provide a lot more hooks for them.
Then add a GCC option you build GCC with, -finstrument-functions.
Wait - that already exists! Or do you maybe mean a more structured
way to expose GCC internals?
> Plugins are important for a very social, non-technical reason: nobody today
> is compiling GCC -except the GCC community & ?the linux distribution makers.
> The art of compiling monster software like GCC is almost lost. People don't
> compile free software anymore. (this has changed since the 1980s. At the
> time of SunOS3.5, people did compile gcc & emacs). And I recently discovered
> that compiling GCC is too difficult a task for most GCC users (at least
> outside academia). GCC plugin will help experimental extensions towards this
> population of GCC users (not able or not wanting to compile GCC).
> Another important motivation for plugins is the licence (more exactly the
> legal requirement of FSF ownership). Coding GPLv3 code is accepted by many
> managers & organizations (because the GPLv3 is a mainstream licence), but
> transfering copyright to FSF is painful to most big organizations - because
> it is an unusual procedure -.
Bullshit. Replacing "monster software like GCC" with "moster plugins
like melt" isn't going to help. It will just fragment the developer
communities.
> This is why defining a large enough set of hooks is important *today*
> [especially for hooks or events easy to implement today]. I am pretty sure
> that gcc-4.5 will still be a lot used in 2013 or 2017, when the GCC
I am pretty sure it will not. I am pretty sure no single plugin developer
will keep its plugin compilable for gcc 4.5 in 2013.
> community will be working on GCC-5.5 or even 6.5 (I know about some small
> SMEs in the embedded software economy which are using today a 2.95 version
> of GCC, and not really able to compile a 4.3 version of GCC, even if
> produces better code for their embedded ARM processor). So the set of hooks
> today is important for many years!
They can patch in hooks as they like. Their plugins will only work
against a patched GCC anyway.
> Notice also another thing. there have been a lot of plugin experimentation
> (at least in GCC summit papers). And every experiment was about code which
> the developer thought would never be accepted into the trunk (and that
> intuition is right: nothing of all the plugin experiments landed into the
> trunk [for example, TreeHydra did not land inside GCC, etc.], except the
> idea of plugins and the small plugin API).
Ah, I responded to that already.
> This means that plugins would probably appear mostly for things that have no
> chance to land into GCC core. Plugin will more proably do everything but the
> kitchen sink. I would expect AMD & Intel to continue contributing to the GCC
> core to target their newest processors - I cannot imagine why AMD or Intel
> would target their 2011 processor with only a plugin.
> [there is a simple reason for that: plugin are a bit more expensive to use
> that straight GCC - you need extra options & extra installations-, and human
> nature is lazy; the interest of constructors is to sell chips, not GCC
> plugins!]. Toplevel processor makers will continue to work inside GCC.
So you believe the only changes in GCC that will happen is newer
processor support? That's sad.
> What could happen if some plugin events are not added quickly? People
> interested in them will simply lose interest in GCC (they could for instance
> go towards LLVM if they feel it is easier for them). People waited much too
> long for plugins to appear... they won't wait till 4.6 for an event
> essential for them which is basically a dozen-line patch; they will just
> stop looking at (or inside) GCC
Good. People not wanting or being able to interact with the GCC
developer community neither do have a chance to successfully
develop a plugin nor are they of interest to GCC.
> If the GCC community cared about experimental languages front-end (stuff
> like Modula3, or Mercury, ...), we should also have hooks for other
> front-ends [I personally have no real need for that]. As a concrete example,
> GNU CLISP could use GCC instead of GNU lightning (to translate its custom
> bytecode into binary). No, I am not volunteering -and when needing a Common
> Lisp, I'll use SBCL.
The frontend interface is very well separated nowadays. Pluginifizing
it should be possible - but please - this needs at least _some_ work
inside GCC. Plugins never should be an excuse to not improve or
fix GCC, instead they should offer an opportunity to do so.
> So in ?contrast to Richard Guenther, I don't percieve any danger today in
> adding several new plugin events (even if they later happen to be nearly
> useless). Precisely because the plugin API is newborn.
We don't add GCC internal APIs like that, so why should plugin APIs
any different here? On the contrary - the hurdle to add external
interfaces should be much higher than adding internal ones.
> We should not be afraid of new plugin events. We could be afraid of people
> wanting to start coding plugins going elsewhere (to some other compiler
> technology).
I'm not afraid of the second.
> I am not afraid of ICI or TreeHydra guys adding useless plugin events. I am
> afraid of ICI or TreeHydra guys losing interest in GCC (and perhaps going to
> other compilers). If that happens, it will be a loss for the GCC community.
I do not see them as part of the GCC community (sorry, no offense intended,
exaggerating again here).
> Regards.
>
> PS. It could also be the case that plugin hooks could be bypassed by
> sophisticated ld.so tricks like LD_PRELOAD.
Oh, so you noticed! Plugins on steroids. Not even sophisticated, but
simpler.
Richard.