-fno-inline-functions vs glibc's initfini
Alexandre Oliva
aoliva@redhat.com
Tue Jan 31 15:40:00 GMT 2012
glibc 2.15 won't build with GCC 4.7ish on ppc64: -fno-inline-functions
is no longer enough to prevent call_gmon_start from being inlined into
initfini.c's _init, as required by glibc's somewhat convoluted
compilation of initfini.c into crt*.o. As a result of the inlining, a
branch and its target label end up in separate object files, after the
compiler's assembly output is broken up in pieces.
I suppose this could be easily worked around in glibc, by using
attribute noinline (and noclone, for good measure, for partial inlining
of the gmon_start undef-weak test would be just as damaging), or
compiling sysdeps/generic/initfini.c with
-fno-inline-functions-called-once (if available), and perhaps also
-fno-inline-small-functions, -fno-indirect-inlining and
-fno-partial-inlining, with room for whatever other options we GCC
developers come up with to control other cases or kinds of inlining.
I'm a bit surprised that -fno-inline-functions doesn't imply all of
these, as long as they're not specified explicitly. IMHO it should.
I'm also surprised that some parts of GCC appear to assume that
-fno-inline was supposed to behave that way, preventing any inlining
whatsoever. Grepping for flag_no_inline shows some hits that appear to
indicate some confusion as to its meaning.
To make matters worse for glibc, it appears that at least
-finline-functions-called-once is already present in earlier releases of
GCC, which means we might have no choice but to bite the bullet and use
this option if it's available, even though I have no evidence that the
implementation controlled by the option caused any problems to glibc's
initfini compilation in already-released versions of GCC.
So, where do we go from here? Is there any reason why glibc doesn't use
the noinline attribute in sysdeps/generic/initfini.c, or for glibc not
to auto-detect -fno-inline-functions-called-once et al and use them in
addition to -fno-inline-functions to compile initfini.c?
As for GCC, shouldn't we aim at providing a stable, reliable option that
prevents inlining of functions not marked always_inline, regardless of
special cases and exceptions to the general inlining rules we might come
up with in the future? Also, shouldn't the implementation of
-finline/-fno-inline be adjusted to match the documentation, and have
flag_no_inline_functions become what we test for as flag_no_inline in
some functions that make decisions about whether or not to perform
inlining?
Thanks in advance for feedback and suggestions,
--
Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/ FSF Latin America board member
Free Software Evangelist Red Hat Brazil Compiler Engineer
More information about the Libc-alpha
mailing list