This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Treat plugins as first class citizens
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>, Nick Clifton <nickc at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 14 Mar 2017 10:01:24 -0600
- Subject: Re: RFC: Treat plugins as first class citizens
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <CAFiYyc3rFWLP2E+sYRQ_A00ijd76s21npFuHHE1Xp6X=46hKWQ@mail.gmail.com> <firstname.lastname@example.org> <CAFiYyc3p0EcWYQWXFY3M=Vs6_gBCAwaM8+mSk7MncKFZF1KB2Q@mail.gmail.com>
On 03/14/2017 07:44 AM, Richard Biener wrote:
I think we want plugins for domain-specific analysis. Having a
repository for well developed checkers makes sense to me, particularly
for checkers which are useful across projects.
On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton <email@example.com> wrote:
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
If you build sth as part of GCC then why is it a plugin in the first place?
One such checker would be Aldy's unencrypted function pointer checker
which finds unencrypted function pointers living in memory (which are
ripe for exploitation by hackers). It's currently most useful for glibc
which has policies WRT unencrypted function pointers, but could well be
used by other projects.
We could also build checkers for resource allocation/deallocation,
I think those checkers are naturally plugins.