This is the mail archive of the mailing list for the glibc 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: GCC plugin to find encrypted function pointer calls in glibc

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

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

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


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