linux-kernel - Re: Old compiler versions (was Re: v4.10: kernel stack frame pointer .. has bad value (null))

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 9 Mar 2017 10:05:03 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Pavel Machek <pavel@....cz>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>,
        Andy Lutomirski <luto@...capital.net>,
        kernel list <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Lutomirski <luto@...nel.org>,
        Borislav Petkov <bp@...en8.de>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        Peter Anvin <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Old compiler versions (was Re: v4.10: kernel stack frame pointer
 .. has bad value (null))

On Thu, Mar 9, 2017 at 2:49 AM, Pavel Machek <pavel@....cz> wrote:
>
> (On thinkpad X220, compiling bzip2)

You really shouldn't assume that the zlib build tracks the kernel build.

At least at some point, a noticeable part of the build cost for the
kernel was just parsing the fairly big source code. We have honking
big include files and deep nesting, and there is a lot of preprocessor
and just general parsing overhead for stuff that in most files don't
even generate code.

All those inline functions and type declarations for things that then
aren't actually used in most files means that you spend relatively
more time just parsing files than you spend on generating and
optimizing code.

So the trade-offs between different projects can be very different.
Some projects have huge tables with static initializers that gcc at
some point had serious quadratic-time issues with, and other code has
big functions where the actual optimization phase is the bulk of it.
And some projects have a lot of big and nested include files.

It's not nearly as bad as some C++ projects (where the header file
mess can often _easily_ be the dominant factor by far), but it's still
potentially completely different from something like building zlib.

Oh, and don't even bother looking at -O0 times. That's almost purely
parsing, but more importantly, the kernel has never in its lifetime
built without optimizations.

We basically rely on the compiler not being moronic crap. Always have,
always will.

> 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
>
>   AS      arch/x86/entry/entry_32.o
>   arch/x86/entry/entry_32.S: Assembler messages:
>   arch/x86/entry/entry_32.S:440: Error: invalid character '"' in
>   operand 1
>
> from the ALTERNATIVE macro. It seems 3.3 just does not like " in macro
> arguments.

Ok. Clearly our checks in <linux/compiler-gcc.h> are outdated, and we
"allow" compilers that don't actually work.

> But that looks fixable. But when I force the compilation, it is
> actually _slower_ than recent gcc (23 minutes vs. 13
> minutes). Interesting.

I forget when gcc got the "integrated preprocessor". It's a long time
ago. But that actually sped things up, because it basically halves (or
more) the overhead of parsing.

With an external preprocessor you obviously first have cpp doing its
parsing, then writing the preprocessed results out, and then you had
cc1 doing parsing again.

So yes, gcc has gotten a lot slower over time, but some things have
actually improved.

                 Linus