linux-kernel - [RFC PATCH 0/2] build: Pass CC, CFLAGS, ... to tools build from main Makefile

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-next>] [day] [month] [year] [list]

Message-Id: <20171003204839.27551-1-dianders@chromium.org>
Date:   Tue,  3 Oct 2017 13:48:37 -0700
From:   Douglas Anderson <dianders@...omium.org>
To:     yamada.masahiro@...ionext.com, mmarek@...e.com, acme@...hat.com
Cc:     groeck@...omium.org, Dmitry Torokhov <dmitry.torokhov@...il.com>,
        mka@...omium.org, Douglas Anderson <dianders@...omium.org>,
        linux-kbuild@...r.kernel.org,
        David Carrillo-Cisneros <davidcc@...gle.com>,
        linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        Jiri Olsa <jolsa@...nel.org>
Subject: [RFC PATCH 0/2] build: Pass CC, CFLAGS, ... to tools build from main Makefile

While trying to enable CONFIG_STACK_VALIDATION in the Chrome OS build
system, Guenter Roeck noticed that the compilation of objtool was
failing in a weird way.  He tracked this down to the fact that,
although the kernel build ignores CFLAGS as of the ancient commit
69ee0b352242 ("kbuild: do not pick up CFLAGS from the environment"),
those the tools builds generally don't ignore CFLAGS.

For the most part it's OK that the tools builds don't ignore CFLAGS.
One could argue that the tools builds really _should_ honor CFLAGS
because, unlike the kernel, they don't need to be special snowflakes.
In general we're just building normal userspace programs and CFLAGS
from the environment can make sense.

...but... When a tools build is invoked from the kernel build then
CFLAGS probably won't make sense.  Specifically the kernel build
expects that "CC" is the _target_ compiler, not the _host_ compiler.
Presumably if CFLAGS is set in the current environment it will match
"CC".  That means it won't make a lot of sense to use when building
tools.

Technically we could just "fix" this by blanking out CFLAGS in the
call to the tools build, just like we've always done for LDFLAGS.
That would fix the problem that Guenter saw.  ...but we probably want
to go a step further.

In general it seems non-ideal that, even if someone overrides HOSTCC
in the kernel, that the tools build will still go back to a hardcoded
"gcc".  It seems like the compiler provided to the kernel as HOSTCC
really ought to be the compiler used in the tools build.  That seems
like it will be important for clang work.  The patches in this series
attempt to do that.

NOTE: I personally am not spending lots of time on clangification of
the kernel (though many of my colleagues are), so I haven't confirmed
that this is actually useful to clang.  It just seemed like a good
fix.  I also continue to assert that I'm not a kernel build expert, so
I've marked this as RFC in the hopes that people will not scream too
loudly if this is a stupid thing to do.  ;-)

Douglas Anderson (2):
  kbuild: Pass HOSTCC and similar to tools Makefiles
  tools build: Take CC, AS, and LD from the command line

 Makefile                       | 30 ++++++++++++++++++++++++++++--
 tools/scripts/Makefile.include | 22 ++++++++++++++++++++--
 2 files changed, 48 insertions(+), 4 deletions(-)

-- 
2.14.2.920.gcf0c67979c-goog