public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox