On Wed, Mar 14, 2018 at 5:34 PM, Martin Jambor <mjam...@suse.cz> wrote: > Hello Prashant, > > On Thu, Mar 08 2018, prashant kumar wrote: >> Hello sir my self *Prashant kumar *second year B.TECH student and i am >> interesting in *"GCC plugin Api" *project .i have a good hand in c,c++ >> languages .Can u tell me what the further process i have to do and what >> kind of thing i have to do > > first and foremost, please discuss any GSoC idea or topic, use the > gcc@gcc.gnu.org mailing list (CCed), this way other people may also > participate in the discussion which will eventually help you as well. > Moreover, in your particular case, you sent me your message while I was > on vacation and so it took quite some time before I got to replying. > Other members of the GCC community might have done that meanwhile. > > The aim of the gcc API project would be to start building a real GCC API > for plugins, so that simple but already useful plugins (operating on > GIMPLE level) could be written that use only this API (as opposed to the > current state where they can - actually they have to - use any normal > public symbol there is in GCC. I do not think it is reasonable to > attempt make the API really entirely compiler agnostic but whenever > practical, the interface should be built on top of generic compiler > constructs (e.g. statements and operands as opposed to gimple and > trees), for many reasons. > > In the first half of the project one would aim to build various dumping > plugins... that would simply dump CFG, statements and perhaps also some > information about types queried through the new interface. In the > second half, you should try to rewrite some existing simple plugins > using this API (such as https://pagure.io/funcp-encrypt that is > described at > https://developers.redhat.com/blog/2017/03/17/diagnosing-function-pointer-security-flaws-with-a-gcc-plugin/ > or perhaps the structleak_plugin.c kernel GCC plugin or > https://rwmj.wordpress.com/2016/02/24/playing-with-gcc-plugins/ though I > have not had a very close look any of those). > > If you are interested, make sure you can check out the GCC trunk source > code, can build GCC from it. The following links should help you: > > - How to check out our sources using svn and git is described at > https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror > respectively. > > - Steps linked from https://gcc.gnu.org/install/ show you how to > configure, build and test GCC is described in (look for > --disable-bootstrap, among other things). > > - Also make sure you also look at https://gcc.gnu.org/wiki/InstallingGCC and > https://gcc.gnu.org/wiki/GettingStarted wiki pages. > > And while you are at it, try also to look at the source. But you have > gone through all of the above and still find a little bit intimidating > or difficult to see where to start looking, do not despair. That is > something the mentors and the community at large are willing to help > you with. > > Regarding plugins, I'd suggest reading one ore more tutorials on their > current implementation > (e.g. http://thinkingeek.com/2015/08/16/a-simple-plugin-for-gcc-part-1/) > and then look at some real plugins to get the sense of what would need > to be APIzied.
Note that there are also (half-way?) finished implementations, several that allow writing plugins in other languages (python, etc.) that usually come with "shim" layers to support multiple GCC versions underneath. Those "shim" layers are a good hint at what needs abstracting. There's also an incomplete attempt at providing a mostly compiler-agnostic plugin API for introspection (but techincally not limited to that). Not sure if Micha ever posted what he had implemented. If I had to choose then I would suggest to embed a "common" shim layer into GCC itself and call that the C plugin API. The python plugin API implementation should be able to bolt on that as well as the introspection API. This means the GSoC project would be about implementing such a layer (and eventually simply start by picking one of the available out-of-tree ones, massaging it so it can replace the others). And of course documenting it, doing some "real" example plugins using that layer directly. Richard. > Good luck, > > Martin
