On Mon, Feb 12, 2018 at 6:39 AM, Masahiro Yamada
> 2018-02-12 2:56 GMT+09:00 Kees Cook <keesc...@chromium.org>:
>> I think it would work to skip KBUILD_CPPFLAGS right up until it
>> didn't. Since we have the arch split, we can already add -m32 to the
>> 32-bit case, etc. However, I worry about interaction with other
>> selected build options. For example, while retpoline doesn't interact
>> stack-protector, it's easy to imagine things that might.
I want to be sure I clarify: I'm not aware of any negative interaction
between stack-protector and other options at present. I was just
trying to think of an illustrative example. I do know we're about to
get some per-architecture stack protector options (e.g. arm64 using a
per-process canary instead of global), but I *think* that can be
handled in the new Kconfig too.
> One ugly solution could be
> to add one more CC_HAS_ for the combination of the two ?
Yeah, that seems reasonable, but it's a fix after the fact. I guess
we'll have to see.
>> (And in thinking about this, does Kconfig know the true $CC in use?
>> i.e. the configured cross compiler, etc?)
> I was thinking of removing CONFIG_CROSS_COMPILE.
> A user can dynamically change CROSS_COMPILE from
> "make menuconfig".
Most builds I've seen implement cross compilers as an environment
variable during all "make" invocations.
> If we continue to support this, $CC changes
> according to CONFIG_CROSS_COMPILE.
> Then, compiler flags must be re-evaluated
> every time a user changes a compiler in use.
> It will introduce much more complexity.
Right now, this is just handled in the Makefile: all the right
variables exist, etc.