Old compiler versions (was Re: v4.10: kernel stack frame pointer .. has bad value (null))
From: Pavel Machek
Date: Thu Mar 09 2017 - 05:50:37 EST
> > > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug
> > > where the stack gets aligned before the mcount call. This issue
> > > should be mostly obsolete as most modern compilers now have -mfentry.
> > > We could make it dependent on CC_USING_FENTRY.
> > Yeah. At some point we might even upgrade the compiler requirements to
> > no longer accept the mcount model.
> > I think the fentry model is gcc-4.6.0 and up. Currently I guess we
> > support gcc-3.2+, which is fairly ridiculous considering that 4.6.0 is
> > from March, 2011. So it's over five years ago already.
> > gcc-3.2.0 is from 2002, I think. At some point you just have to say
> > "caring about a 15 year old compiler is ridiculous"
> > The main reason we have fairly aggressively supported old compilers
> > tends to be some odder architectures that don't have good support, so
> > people use various random "this works for me" versions.
> > We could easily make the gcc version checks much more strict on x86,
> > I suspect.
> Well, I have fast CPUs, but most of the time they just compile
> stuff. Especially bisect is compile-heavy. I suspect going back to
> gcc-3.2 would bring me bigger advantages than CPU upgrade...
Okay, would not it be nice if we supported gcc-3.3? It compiles about
twice the speed of gcc-4.9, across the board: (If we could compile at
-O1, we'd get 4 times the speed. At -O0, we'd be at cca 9 times the
speed; that would be useful for a bisect!)
Good news is that -Os is quite significantly faster than -O2 (and
already supported), so that should be simple way to optimize bisect performance.
(On thinkpad X220, compiling bzip2)
| mach | gcc | | | real | user | sys | $
| x220 | 4.9.2-10 | -O0 | bzip2.c caf036 | 0.644 | 0.54 | 0.03 | $
| | | -O1 | | 1.501 | | | $
| | | -O2 | | 2.607 | | | $
| | | -O3 | | 3.052 | | | $
| | | -Os | | 1.839 | | | $
| | 3.3.5-13 | -O0 | | 0.343 | 0.300 | 0.028 | $
| | | -O1 | | 0.721 | | | $
| | | -O2 | | 1.238 | | | $
| | | -O3 | | 1.598 | 1.508 | 0.032 | $
Unfortunately, 4.11-rc1 fails to compile on gcc 3.3.5.
> 1. None (CC_STACKPROTECTOR_NONE) (NEW)
is needed. Easy. But then I get
arch/x86/entry/entry_32.S: Assembler messages:
arch/x86/entry/entry_32.S:440: Error: invalid character '"' in
from the ALTERNATIVE macro. It seems 3.3 just does not like " in macro
arch/x86/boot/bioscall.S: Assembler messages:
arch/x86/boot/bioscall.S:68: Error: `68(%esp)' is not a valid 16 bit
Plus I get about milion of
include/linux/irq.h:419: warning: parameter has
include/linux/irq.h:420: warning: parameter has
... and problem with builtin_ffs in drm_blend.c, and others with
function alignment in drm.
lzo1x_compress needs __builtin_ctz. In the end, compilation fails with
mm/built-in.o(.text+0x2b714): In function `do_set_pmd':
: undefined reference to `__compiletime_assert_3034'
mm/built-in.o(.text+0x2c09a): In function `create_huge_pmd':
: undefined reference to `do_huge_pmd_anonymous_page'
mm/built-in.o(.text+0x2c0ca): In function `wp_huge_pmd':
: undefined reference to `do_huge_pmd_wp_page'
drivers/built-in.o(.text+0xe5a2b): In function
: undefined reference to `__compiletime_assert_2638'
drivers/built-in.o(.text+0x3c969f): In function `sg_ioctl':
: undefined reference to `__divdi3'
But that looks fixable. But when I force the compilation, it is
actually _slower_ than recent gcc (23 minutes vs. 13
minutes). Interesting. If someone knows what old gcc versions actually
compile recent kernels, I'd like to know.
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Description: Digital signature