Sean, I don't really think most people are contributing to GCC for the bragging rights (at least I am not :-)). I would consider this a concerted, collaborating effort to get a simple, robust, and accommodating plugin design and implementation out as quickly as possible so that people can start using it. We offered to start with our patch simply because we had an implementation of the originally proposed APIs and we wanted to get the ball rolling quickly. As I mentioned in my previous email, if you (or other people/groups) have an implementation of the proposed APIs and prefer to start with yours (or theirs), I am all for it. (And please send the patch out so that people can look at it. Thanks.)
Based on our initial experience, it's not that huge a task to implement basic GCC infrastructure supports for plugins. In fact, all the tasks you listed have been implemented in our patch (or in any other implementations, I believe), although there are certainly some corner cases that we didn't consider and some issues that have yet to converge. I think we just need to get started with an implementation of the proposed APIs (of course after reviewing and everything), and people can start iterating on that and adding new features/enhancements. (It's actually great that many of us have experiences implementing the plugin supports so that collectively we can cover more corner cases.) (BTW, a colleague pointed out to me that with my name in the header comment of the source files in our patch, people might have an impression that I am taking all the credits. That's certainly not my intention. I simply copied it from a standard header template that I kept for my GCC development. If we decide to start with that patch, I will certainly take it out.) Regards, Le-chun On Fri, Feb 6, 2009 at 2:54 AM, Sean Callanan <spy...@cs.sunysb.edu> wrote: > 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 practice, Diego said that we have "several months" before we need to > integrate. Diego has graciously agreed to review patches; how about instead > of having a single implementation that goes in, we all pool our development > resources and do different portions of a fresh implementation? We could put > up a list of tasks on the Wiki and assign them to groups, so that everybody > has a hand in it. > > A possible list of tasks (which could each have a patch to itself) is: > > - Modify the GCC link process to use libltdl and libtool -export-dynamic > - Add the custom argument handler > - Implement the callback registration code > - Add hooks at relevant locations in GCC > - Implement the plug-in loading code and plug-in initialization > > Sean > > On Feb 5, 2009, at 7:14 PM, Le-Chun Wu wrote: > >> 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 > >
