* RFC: Treat plugins as first class citizens
@ 2017-03-13 17:12 Nick Clifton
2017-03-14 8:20 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Nick Clifton @ 2017-03-13 17:12 UTC (permalink / raw)
To: gcc
Hi Guys,
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. For example:
gcc/plugins <-- Everything plugin-y starts here
gcc/plugins/Make-lang.in <-- Makefile fragment.
gcc/plugins/src <-- Maybe move gcc/plugins.[c|h|def] here ?
gcc/plugins/doc <-- Actual documentation, wow!
gcc/plugins/testsuite <-- Tests for the plugins and their integration into gcc
gcc/plugins/config <-- Subdirectories of this directory contain each real plugin
gcc/plugins/config/annobin <-- For example, this is where my pet plugin would go
Plus there could be an official plugins maintainer. (I am willing to
volunteer, so is Aldy Hernandez). The documentation would be compiled
along with the rest of gcc's documentation and the testsuite would be
run as part of gcc's normal testing process. Ideally I would also
like to see plugin test failures be considered as blockers for new
releases, but that is something for the future.
So, what do you think ? Should I create a patch and submit it for
official review ?
Cheers
Nick
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Treat plugins as first class citizens
2017-03-13 17:12 RFC: Treat plugins as first class citizens Nick Clifton
@ 2017-03-14 8:20 ` Richard Biener
2017-03-14 13:38 ` Nick Clifton
0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2017-03-14 8:20 UTC (permalink / raw)
To: Nick Clifton; +Cc: GCC Development
On Mon, Mar 13, 2017 at 6:12 PM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Guys,
>
> 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. For example:
>
> gcc/plugins <-- Everything plugin-y starts here
> gcc/plugins/Make-lang.in <-- Makefile fragment.
> gcc/plugins/src <-- Maybe move gcc/plugins.[c|h|def] here ?
> gcc/plugins/doc <-- Actual documentation, wow!
> gcc/plugins/testsuite <-- Tests for the plugins and their integration into gcc
> gcc/plugins/config <-- Subdirectories of this directory contain each real plugin
> gcc/plugins/config/annobin <-- For example, this is where my pet plugin would go
>
> Plus there could be an official plugins maintainer. (I am willing to
> volunteer, so is Aldy Hernandez). The documentation would be compiled
> along with the rest of gcc's documentation and the testsuite would be
> run as part of gcc's normal testing process. Ideally I would also
> like to see plugin test failures be considered as blockers for new
> releases, but that is something for the future.
>
> So, what do you think ? Should I create a patch and submit it for
> official review ?
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".
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.
I'm still convinced that 99% of all (valid) plugin uses involve only
introspection
or well-defined instrumentation.
Richard.
> Cheers
> Nick
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Treat plugins as first class citizens
2017-03-14 8:20 ` Richard Biener
@ 2017-03-14 13:38 ` Nick Clifton
2017-03-14 13:44 ` Richard Biener
0 siblings, 1 reply; 6+ messages in thread
From: Nick Clifton @ 2017-03-14 13:38 UTC (permalink / raw)
To: Richard Biener; +Cc: GCC Development
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.
> 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.
Cheers
Nick
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Treat plugins as first class citizens
2017-03-14 13:38 ` Nick Clifton
@ 2017-03-14 13:44 ` Richard Biener
2017-03-14 16:01 ` Jeff Law
0 siblings, 1 reply; 6+ messages in thread
From: Richard Biener @ 2017-03-14 13:44 UTC (permalink / raw)
To: Nick Clifton; +Cc: GCC Development
On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton <nickc@redhat.com> 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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Treat plugins as first class citizens
2017-03-14 13:44 ` Richard Biener
@ 2017-03-14 16:01 ` Jeff Law
2017-03-20 9:26 ` Aldy Hernandez
0 siblings, 1 reply; 6+ messages in thread
From: Jeff Law @ 2017-03-14 16:01 UTC (permalink / raw)
To: Richard Biener, Nick Clifton; +Cc: GCC Development
On 03/14/2017 07:44 AM, Richard Biener wrote:
> On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton <nickc@redhat.com> 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 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.
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,
locking/unlocking, etc.
I think those checkers are naturally plugins.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: Treat plugins as first class citizens
2017-03-14 16:01 ` Jeff Law
@ 2017-03-20 9:26 ` Aldy Hernandez
0 siblings, 0 replies; 6+ messages in thread
From: Aldy Hernandez @ 2017-03-20 9:26 UTC (permalink / raw)
To: Jeff Law; +Cc: Richard Biener, Nick Clifton, GCC Development
Jeff Law <law@redhat.com> writes:
>> If you build sth as part of GCC then why is it a plugin in the first place?
> 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.
>
> 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.
FYI:
https://developers.redhat.com/blog/2017/03/17/diagnosing-function-pointer-security-flaws-with-a-gcc-plugin/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2017-03-20 9:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-13 17:12 RFC: Treat plugins as first class citizens Nick Clifton
2017-03-14 8:20 ` Richard Biener
2017-03-14 13:38 ` Nick Clifton
2017-03-14 13:44 ` Richard Biener
2017-03-14 16:01 ` Jeff Law
2017-03-20 9:26 ` Aldy Hernandez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).