From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130569 invoked by alias); 15 Mar 2018 08:43:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 130559 invoked by uid 89); 15 Mar 2018 08:43:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=bolt, underneath, H*f:sk:ri6a7va, H*i:sk:ri6a7va X-HELO: mail-lf0-f42.google.com Received: from mail-lf0-f42.google.com (HELO mail-lf0-f42.google.com) (209.85.215.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Mar 2018 08:43:50 +0000 Received: by mail-lf0-f42.google.com with SMTP id l191-v6so8923863lfe.1 for ; Thu, 15 Mar 2018 01:43:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4QJiFdwYJrsd/byFyiTSKicvKTCGAC9K3zLf+zLr3K4=; b=s39XbOGJ0bM9DliGdPQC4i95uCMStcwa4ldywVUlBkesu1DvWc7eNnVsQSSnHFQRUh Ml3rrYCb1vPY+rqpRoCgiINFVP9+7UwlI2fomsNdBRbQAXA4YN9NzkgYKMqCZ5E4Q91R vOq+mYMgg7wUJMTANql1pqHgXglxN2xryvmhLHYofT0dgctKeWQSdanp4t5SL7QhkAZi dVZxyIPBmLyr6/O1m5aylaxuqQfqTvQos0hJjbZsTw5zWs3o8lZWelG3+YwWITqF/DFK Pccg4vS9m/QxCA0IqOiC+v+8FvhYnnmP61BvdcKEKSi595QCgxdAlhFHUK/jhK50Wox1 SIDA== X-Gm-Message-State: AElRT7F6J92IJsPWuNExR+hiPvfMcmaTo5bpxdx1kojQGi66U4pHPa8S sbVyiSXoRjTR7NXRg6xqPG4HIlOOhk/rYtGbtX0= X-Google-Smtp-Source: AG47ELtR9n1+J0TjUmk8zxgRZETRCXoGIpJRmUdCzx/9Q4Ja3EGN0arqmyLqpF2lZtZMZpyRSpEpaYxxje1VZ5BFpao= X-Received: by 10.46.41.90 with SMTP id u87mr5354672lje.112.1521103427634; Thu, 15 Mar 2018 01:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.150.140 with HTTP; Thu, 15 Mar 2018 01:43:47 -0700 (PDT) In-Reply-To: References: From: Richard Biener Date: Thu, 15 Mar 2018 08:43:00 -0000 Message-ID: Subject: Re: GSOC To: Martin Jambor , Michael Matz Cc: prashant kumar , GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00167.txt.bz2 On Wed, Mar 14, 2018 at 5:34 PM, Martin Jambor 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