Messages in this thread |  | | From | Linus Torvalds <> | Date | Fri, 13 Apr 2018 11:11:56 -0700 | Subject | Re: [PATCH 21/30] stack-protector: test compiler capability in Kconfig and drop AUTO mode |
| |
On Fri, Apr 13, 2018 at 9:41 AM, Kees Cook <keescook@chromium.org> wrote: > > How about something like this instead:
I'd rather avoid the ifdef's in the Makefile if at all possible.
I'd rather expose this as a Kconfig rule, and in the Kconfig just have an entry something like this
config STACKPROTECTOR_FLAGS string default "-fstack-protector-strong" if CC_STACKPROTECTOR_STRONG default "-fstack-protector" if CC_STACKPROTECTOR default "-fno-stack-protector" if CC_HAS_STACKPROTECTOR_NONE default ""
which is really simple and straightforward. In the presense of multiple defaults, the first is picked, so this _automatically_ does that whole priority ordering.
And then the Makefile can just have
KBUILD_CFLAGS += $(CONFIG_STACKPROTECTOR_FLAGS)
which seems much simpler.
It also makes more complex conditionals easier (ie different compilers with different flags, since clang sometimes does the same thing with another flag name), so I'd rather see this pattern in general.
I'd also *much* rather do as much as possible at Kconfig time compared to build time. Maybe it's just shifting the costs around, but the less "clever" things we ask "make" to do, the better.
I find our Makefiles an odd combination of really clean and simply (the ones that just have "obj-$(CONFIG_X) += xyz.o" are just lovely) and completely incomprehensible (all of our infrastructure support for the simple stuff).
I'd rather have more of the simple stuff in Makefiles, less of the complex conditionals.
Linus
|  |