This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: GCC plugin to find encrypted function pointer calls in glibc
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org, Florian Weimer <fweimer at redhat dot com>
- Date: Thu, 5 May 2016 06:10:34 -0400
- Subject: Re: RFC: GCC plugin to find encrypted function pointer calls in glibc
- Authentication-results: sourceware.org; auth=none
- References: <57233606 dot 7050205 at redhat dot com> <57240891 dot 1000308 at redhat dot com> <5724D5E3 dot 8050600 at redhat dot com> <572A0045 dot 2050309 at redhat dot com>
On 05/04/2016 09:59 AM, Carlos O'Donell wrote:
On 04/30/2016 11:57 AM, Aldy Hernandez wrote:
I take it option 3 is too disgusting, provided #1 is a no go? That
is, adding a carefully crafted comment at the end of an inline asm
string?
Option 3 is a non-starter.
I think a static inline wrapper is going to be just fine if the compiler
does a good job of the generated code.
It does, and if it doesn't, it's a compiler bug that must be fixed.
Errr, and by the way, is it a requirement that this plugin work with
4.7? Because, we only need this for static analysis. Is building
glibc twice a no go (once with the plugin for static analysis, and
once for building the actual production code)? I thought the purpose
of the plugin was just to analyze what's already there, but I do see
the benefit of using the same compiler for static analysis _and_ for
building the library.
You misunderstood. Let me clarify. If you add new attributes to the source
then the compiler that compiles glibc must know about those new attributes
or we must conditionally enable/disable them. If we conditionally enable
and disable them, then this will seriously impact the output of the plugin
in ways which aren't immediately obvious. Consider building with an older
gcc, and now the plugin (using a newer gcc) starts raising lots of errors.
The gcc used to build glibc should not have a material impact on the results
of the plugin.
You can leave the attributes enabled unconditionally. GCC ignores
unknown attributes, so the old compiler compiling the attributed source
will behave as usual.
However, you will get an "unknown attribute ignored" warning with -Wall,
but you can easily silence that particular warning just for the wrapper:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wattributes"
static inline void
__attribute__((SOME_POSSIBLY_UNKNOWN_ATTRIBUTE))
wrapper_function (void)
{
}
#pragma GCC diagnostic pop
If the same compiler is a requirement, the plugin requires some
rewriting, because unfortunately, the plugin infrastructure is a
moving API target. I doubt a plugin for GCC 6 will even compile the
boiler plate nonsense we need for another GCC version (and vice
versa).
That's fine.
What I would like to see is:
(a) In-tree plugins.
(b) A configure option to enable the plugins (default disabled for now).
* Enables source markers to use the appropriate attributes.
* Builds the plugins.
(c) Make it a hard error if a compiler recent enough to build them is
not present.
This way the individual developers can use CI to do a glibc build with
this option enabled and look for errors.
Sounds good. I'll leave Florian and the rest of you glibc gurus to
those details :).
Aldy