linux-kernel - Re: Thoughts about introducing OPTIMIZATION

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]

Message-ID: <CA+icZUWxfbPN4URoVdBAwm22sdKqGmTtiNBEg-KoHi-vgGqzqg@mail.gmail.com>
Date:	Fri, 8 Jan 2016 11:03:12 +0100
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Michal Marek <mmarek@...e.cz>
Cc:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Sam Ravnborg <sam@...nborg.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Arnd Bergmann <arnd@...db.de>, Ingo Molnar <mingo@...hat.com>,
	linux-kbuild@...r.kernel.org,
	Linux ACPI <linux-acpi@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: Thoughts about introducing OPTIMIZATION_CFLAG

On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@...e.cz> wrote:
> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>> But I think you did not get my problem - to have two different
>> optimization-levels for a compiler in *one* make-line makes no sense
>> to me.
>
> That we sometimes have -O2 ... -Os on the command line is not a problem,
> since any same unix tool parses its options so that the last one of
> mutually exclusive options wins.

That is new to me and I haven't tested this by dropping arguments in
my make-line(s).

>From where do have this information - sort of "business-life-experience" :-)?
Is that documented somewhere in the Linux-sources?

What means "last one" - last one seen from the begin-of-(make)-line?

Do you agree that it is confusing to have two optlevel arguments in
one make-line?

Linus suggested me to use a wrapper-script in case of using two
different compiler and passing arguments...

[  /usr/bin/mycompiler ]
#!/bin/bash

gcc-4.9 "$@"
- EOF -

According to your statement passing an optlevel here in this script
will never-ever be recognized - as it is at the begin-of-(make)-line.

So how should someone change the Linux-sources to test a different
optlevel than -O2?

I have also seen that below arch/x86 there exists hardcoded -O2 and
-Os which are placed after -O2 (default value from the
toplevel-Makefile).

Thoughts?

> As to -Os vs. -Oz, to my knowledge
> clang accepts both and -Oz means to reduce size by any means. If -Oz is
> more appropriate for the CONFIG_CC_OPTIMIZE_FOR_SIZE case and/or for the
> individual object files, feel free to change it, but please do not
> introduce another variable holding compiler options.
>

JUST FYI...
I was able to compile a llvmlinux-patched Linux v4.4.-rc8 with -Os and
CLANG v3.7.1.
Dunno the difference between -Os and -Oz.
The bug-line still exists with both.

Still I want to know if the problem exists with a different optlevel
like -O0 or -O1 or -O3.
Cannot say if all clang-specific compiler-flags will be available in
these optlevels.
( Testing with hardcoded -O0 ended in a build-breakage. )
That would be helpful to check if it is a compiler-optimization bug.

Can you help me in having a switchable value for the "default"
optlevel (which is currently -O2) in the Kconfig system?

We have CC_OPTIMIZE_FOR_SIZE in init/Kconfig.

What about a CC_OPTIMIZE_DEFAULT as a string in init/Kconfig?

[ init/Kconfig ]

config CC_OPTIMIZE_DEFAULT
        string
        default="-O2"

config CC_OPTIMIZE_FOR_SIZE
        bool "Optimize for size"
        help
          Enabling this option will pass "-Os" instead of "-O2" to
          your compiler resulting in a smaller kernel.

          If unsure, say N.

[ Makefile (top-level ]

OPTIMIZE_CFLAGS := $(subst $(quote),,$(CC_OPTIMIZE_DEFAULT))
...
KCONFIG_CFLAGS += $(OPTIMIZE_CFLAGS)
...

Unfortunately, that is not working as expected.

Something like the above would help not to hack in the Linux-sources
and pass elegantly a default-optlevel via Kconfig-system.

If there is an easier way of passing and using a different optlevel,
then please let me know.

Still digging in the dark on how to change to have one single optlevel.

Is it in general possible to "override" the default -O2
(toplevel-Makefile) for a specific part/subsystem?
Other possibilities than via the Kconfig-system?

Thanks in advance.

- Sedat -