Re: GSOC

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Mar 14, 2018 at 5:34 PM, Martin Jambor <mjambor@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