From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127689 invoked by alias); 14 Mar 2017 13:44:41 -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 127664 invoked by uid 89); 14 Mar 2017 13:44:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=smoke, H*f:sk:354ea3f, H*i:sk:354ea3f, plugins X-HELO: mail-ot0-f173.google.com Received: from mail-ot0-f173.google.com (HELO mail-ot0-f173.google.com) (74.125.82.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Mar 2017 13:44:39 +0000 Received: by mail-ot0-f173.google.com with SMTP id i1so135879926ota.3 for ; Tue, 14 Mar 2017 06:44:40 -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=zA/FxC++QRr6w2SOpc+F4j90jpowu71BV5zFcmhwyPg=; b=jlkgtyzRd41aQuuKRGez6Ac2MHomenwOdAqIU19JRjMtaymyocggC9EbsHXqyX9sAF djrOGerSdQmwd7G3BJx8Q9YSSu12UgbvNPYqPsgEKmgpaHz1/WhM2wjbTw8nkXwpPZQg nWwhRUdUAdlfbLkemhDdMWfbzvOSpG9IDj7f6+IHbAKBq8JalbXPAyTTVg967QKGvwWu 8K0kC9m6OojlduZpIlDu0Ix4f4DHhR24Nxc4C1ESSokEef3iwG+i9xLxuZGaa4xGoNQo 9u8QcqzwOOv1bf6sDOunig2vI542odySTwcpEhASiCPl1Gfh7rA57ryGWvTKL4iEaohc cE1w== X-Gm-Message-State: AMke39mktnteF+LnVn+GcYR2NKCkzPMqnx5wtf1virkwEDyKHMBN3N4vh7LkfKlSTBt3Q5bxGtZtAqazk/lD3A== X-Received: by 10.202.190.67 with SMTP id o64mr17931954oif.0.1489499078637; Tue, 14 Mar 2017 06:44:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.25 with HTTP; Tue, 14 Mar 2017 06:44:38 -0700 (PDT) In-Reply-To: <354ea3ff-7c79-0f15-6cbc-e629c9270955@redhat.com> References: <87vardgkxe.fsf@redhat.com> <354ea3ff-7c79-0f15-6cbc-e629c9270955@redhat.com> From: Richard Biener Date: Tue, 14 Mar 2017 13:44:00 -0000 Message-ID: Subject: Re: RFC: Treat plugins as first class citizens To: Nick Clifton Cc: GCC Development Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00069.txt.bz2 On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton wrote: > Hi Richard, > >>> I was thinking that it would be nice to make plugins a "first-class >>> citizen" in the gcc world by having a proper directory structure and >>> integration into the rest of gcc. > >> I believe plugins are currently a hack due to the lack of a clearly defined >> API to access GCC internals. Unless that is resolved somehow, see various >> half-way finished patch prototypes from two (or three?) years ago treating >> them as "first class" would be a blatant labeling lie. It's at most >> "first class mess". > > One of the goals of this proposal is to help combat this mess by making plugins > a respected and official part of gcc. Such that, when the plugins fail to build, > test or install, the problem would be considered a blocker and it would have to > be fixed before the sources are released. > > At the moment nobody (well almost nobody) cares about > > >> The most obvious "proof" of the broken current state is that plugins are broken >> all the time because at make install time we forget to install another >> of the GCC internal headers. The bug is of course that we need those at all. > > Presumably you are talking about the ability to build plugins using an installed > version of gcc ? This is separate from this proposal which is about building and > installing plugins at the same time that gcc is built and installed. One possible > way to address this problem is to state that plugins should not be built outside of > a gcc build tree. Or at least any plugins that require intimate access to gcc's > internal headers. If you build sth as part of GCC then why is it a plugin in the first place? >> I'm still convinced that 99% of all (valid) plugin uses involve only >> introspection or well-defined instrumentation. > > I agree, and I would like to see a move towards officially accepting these plugins > into gcc's ecosystem. I'd not like to have a "python plugin" but instead a well-defined C API to GCC internals that supports introspection. And then at some point extend it with instrumentation. Heck, such interface should be compiler-agnostic, so a smoke test for the API sanity is to implement it ontop of LLVM as well so you can share introspection plugins. Richard. > Cheers > Nick > >