From: Matthias Kaehlcke <mka@chromium.org>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"H . Peter Anvin" <hpa@zytor.com>,
"Michal Marek" <mmarek@suse.com>, "X86 ML" <x86@kernel.org>,
"Linux Kbuild mailing list" <linux-kbuild@vger.kernel.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Douglas Anderson" <dianders@chromium.org>,
"Michael Davidson" <md@google.com>,
"Greg Hackmann" <ghackmann@google.com>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Stephen Hines" <srhines@google.com>,
"Kees Cook" <keescook@chromium.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Bernhard Rosenkränzer" <Bernhard.Rosenkranzer@linaro.org>
Subject: Re: [PATCH 1/2] kbuild: Add macros cc-option-3 and __cc-option-3
Date: Mon, 7 Aug 2017 11:33:33 -0700 [thread overview]
Message-ID: <20170807183333.GK84665@google.com> (raw)
In-Reply-To: <CAK7LNAQY6eWiD=JVFbKtEoq2pdLhGJc18OfP97GkyVuFUoAEpA@mail.gmail.com>
Hi Masahiro,
El Mon, Aug 07, 2017 at 10:01:41AM +0900 Masahiro Yamada ha dit:
> Hi Matthias,
>
> Sorry for my late reply.
>
> 2017-08-03 1:46 GMT+09:00 Matthias Kaehlcke <mka@chromium.org>:
> > El Fri, Jul 21, 2017 at 02:56:56PM -0700 Matthias Kaehlcke ha dit:
> >
> >> The macro cc-option receives two parameters (the second may be empty). It
> >> returns the first parameter if it is a valid compiler option, otherwise
> >> the second one. It is not evaluated if the second parameter is a valid
> >> compiler option. This seems to be fine in virtually all cases, however
> >> there are scenarios where the second paramater needs to be evaluated too,
> >> and an empty value (or a third option) should be returned if it is not
> >> valid.
> >>
> >> The macro cc-option-3 receives three parameters and returns parameter 1
> >> or 2 (in this order) if one of them is found to be a valid compiler
> >> option, and otherwise paramater 3. The macro __cc-option-3 works
> >> analogously.
> >
> > Any comment on this?
> >
> > Thanks
> >
> > Matthias
> >
> >> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> >> ---
> >> scripts/Kbuild.include | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
> >> index dd8e2dde0b34..dc83635f2317 100644
> >> --- a/scripts/Kbuild.include
> >> +++ b/scripts/Kbuild.include
> >> @@ -113,6 +113,11 @@ as-instr = $(call try-run,\
> >> __cc-option = $(call try-run,\
> >> $(1) -Werror $(2) $(3) -c -x c /dev/null -o "$$TMP",$(3),$(4))
> >>
> >> +# __cc-option-3
> >> +# Usage: MY_CFLAGS += $(call __cc-option-3,$(CC),$(MY_CFLAGS),\
> >> +# -mpreferred-stack-boundary=2,-mstack-alignment=4,)
> >> +__cc-option-3 = $(call __cc-option,$(1),$(2),$(3),$(call __cc-option,$(1),$(2),$(4),$(5)))
> >> +
> >> # Do not attempt to build with gcc plugins during cc-option tests.
> >> # (And this uses delayed resolution so the flags will be up to date.)
> >> CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS))
> >> @@ -123,6 +128,10 @@ CC_OPTION_CFLAGS = $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS))
> >> cc-option = $(call __cc-option, $(CC),\
> >> $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS),$(1),$(2))
> >>
> >> +# cc-option-3
> >> +# Usage: cflags-y += $(call cc-option-3,-mpreferred-stack-boundary=3,-mstack-alignment=8,)
> >> +cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3)))
>
>
> I do not like this macro much for the following reasons:
>
>
> [1]
> I guess your motivation is to evaluate the second option,
> not receive the third option.
In this case yes, a future use case could be to support another
compiler with different option names, but I suppose we can focus
on the present for now.
> If this is the demand, I thought it might be nicer to
> change cc-option to always evaluate the second option.
I considered that, but was reluctant to change current behavior,
though in practice it shouldn't make a difference.
> (I do no have a good idea for the implementation.)
One option could be a variant of the try-run macro, that receives the
'base command' as first parameter:
try-run-opt = $(shell set -e; \
TMP="$(TMPOUT).$$$$.tmp"; \
TMPO="$(TMPOUT).$$$$.o"; \
if ($(1) $(2)) >/dev/null 2>&1; \
then echo "$(2)"; \
elif [ -n "${3}" ] && ($(1) $(3)) >/dev/null 2>&1; \
then echo "$(3)"; \
else echo ""; \
fi; \
rm -f "$$TMP" "$$TMPO")
__cc-option = $(call try-run-opt,\
$(1) -Werror $(2) -c -x c /dev/null -o "$$TMP",$(3),$(4))
try-run-opt assumes that is is valid to append an option to the end
of the base command.
For consistency we'd probably want to adapt other suitable xx-option
macros as well.
Does this look reasonable to you?
> cc-option-3 = $(call cc-option,$(1),$(call cc-option,$(2),$(3)))
>
> evaluates the inner $(call cc-option,) first.
>
> This works a bit differently from our expectation.
>
>
> For example, let's consider the following case.
>
> $(call cc-option-3,-Oz,-Os,-O2)
>
>
> I think we generally expect -Oz, -Os are tested in this order.
> (If -Oz is supported by the compiler, the test for -Os will be skipped.)
>
>
> In fact, cc-option-3 tests -Os, -Oz in this order
> because inner cc-option is evaluated before the outer one.
> The test for -Os may or may not be necessary.
I agree, running the check for the alternative options always is not
desirable.
prev parent reply other threads:[~2017-08-07 18:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 21:56 [PATCH 1/2] kbuild: Add macros cc-option-3 and __cc-option-3 Matthias Kaehlcke
2017-07-21 21:56 ` [PATCH 2/2] x86/build: Fix stack alignment for CLang Matthias Kaehlcke
2017-08-02 16:46 ` [PATCH 1/2] kbuild: Add macros cc-option-3 and __cc-option-3 Matthias Kaehlcke
2017-08-07 1:01 ` Masahiro Yamada
2017-08-07 18:33 ` Matthias Kaehlcke [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170807183333.GK84665@google.com \
--to=mka@chromium.org \
--cc=Bernhard.Rosenkranzer@linaro.org \
--cc=arnd@arndb.de \
--cc=dianders@chromium.org \
--cc=ghackmann@google.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=md@google.com \
--cc=mingo@redhat.com \
--cc=mmarek@suse.com \
--cc=ndesaulniers@google.com \
--cc=srhines@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.