This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Treat plugins as first class citizens

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
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.


> Cheers
>   Nick

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]