[GIT PULL] Kbuild updates for 4.18 (2nd round)

[GIT PULL] Kbuild updates for 4.18 (2nd round)

[Masahiro Yamada]

Hi Linus,

Please pull more Kbuild updates.  Thanks!



The following changes since commit c90fca951e90ba470a3dc6087667edffcf8db21b:

  Merge tag 'powerpc-4.18-1' of
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
(2018-06-07 10:23:33 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
tags/kbuild-v4.18-2

for you to fetch changes up to 00979ce4fcc90d488c7f27f750097adc6b11bd07:

  linux/linkage.h: replace VMLINUX_SYMBOL_STR() with __stringify()
(2018-06-13 00:03:17 +0900)

----------------------------------------------------------------
Kbuild updates for v4.18 (2nd)

 - fix some bugs introduced by the recent Kconfig syntax extension

 - add some symbols about compiler information in Kconfig, such as
   CC_IS_GCC, CC_IS_CLANG, GCC_VERSION, etc.

 - test compiler capability for the stack protector in Kconfig, and
   clean-up Makefile

 - test compiler capability for GCC-plugins in Kconfig, and clean-up
   Makefile

 - allow to enable GCC-plugins for COMPILE_TEST

 - test compiler capability for KCOV in Kconfig and correct dependency

 - remove auto-detect mode of the GCOV format, which is now more nicely
   handled in Kconfig

 - test compiler capability for mprofile-kernel on PowerPC, and
   clean-up Makefile

 - misc cleanups

----------------------------------------------------------------
Masahiro Yamada (14):
      kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
      stack-protector: test compiler capability in Kconfig and drop AUTO mode
      kconfig: add CC_IS_GCC and GCC_VERSION
      kconfig: add CC_IS_CLANG and CLANG_VERSION
      arm64: move GCC version check for ARCH_SUPPORTS_INT128 to Kconfig
      gcov: remove CONFIG_GCOV_FORMAT_AUTODETECT
      kcov: test compiler capability in Kconfig and correct dependency
      gcc-plugins: move GCC version check for PowerPC to Kconfig
      gcc-plugins: test plugin support in Kconfig and clean up Makefile
      gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
      gcc-plugins: disable GCC_PLUGIN_STRUCTLEAK_BYREF_ALL for COMPILE_TEST
      Documentation: kconfig: add recommended way to describe compiler support
      sh: remove no-op macro VMLINUX_SYMBOL()
      linux/linkage.h: replace VMLINUX_SYMBOL_STR() with __stringify()

Nicholas Piggin (1):
      powerpc/kbuild: move -mprofile-kernel check to Kconfig

Sam Ravnborg (1):
      kconfig: fix localmodconfig

 Documentation/kbuild/kconfig-language.txt       |  18 +++
 Makefile                                        | 147 +++++----------------
 arch/Kconfig                                    |  50 +++----
 arch/arm64/Kconfig                              |   1 +
 arch/arm64/Makefile                             |   6 -
 arch/powerpc/Kconfig                            |  18 +--
 arch/powerpc/Makefile                           |  13 +-
 arch/powerpc/include/asm/module.h               |   2 +-
 arch/powerpc/kernel/module_64.c                 |   4 +-
 arch/powerpc/kernel/trace/ftrace.c              |   6 +-
 arch/powerpc/tools/gcc-check-mprofile-kernel.sh |   1 -
 arch/sh/include/asm/vmlinux.lds.h               |   4 +-
 arch/x86/Kconfig                                |  11 +-
 include/linux/linkage.h                         |  12 +-
 init/Kconfig                                    |  15 +++
 kernel/gcov/Kconfig                             |  17 +--
 kernel/gcov/Makefile                            |   2 -
 lib/Kconfig.debug                               |  11 +-
 scripts/Kconfig.include                         |   3 +
 scripts/Makefile.gcc-plugins                    |  91 +++----------
 scripts/Makefile.kcov                           |  10 +-
 scripts/clang-version.sh                        |  18 +--
 scripts/gcc-plugins/Makefile                    |   5 +-
 scripts/gcc-x86_32-has-stack-protector.sh       |   7 +-
 scripts/gcc-x86_64-has-stack-protector.sh       |   5 -
 scripts/kconfig/streamline_config.pl            |   4 +-
 26 files changed, 173 insertions(+), 308 deletions(-)


-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Linus Torvalds]

On Wed, Jun 13, 2018 at 7:47 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Please pull more Kbuild updates.

Pulled. However, I notice a few oddities.

This causes a non-clang build to have

    CLANG_VERSION=0

in the config file. Maybe that's intentional to simplify other
expressions (ie allow "depends on CLANG_VERSION > xyz" elsewhere), but
it does look a bit odd. It looks like GCC_VERSION does the same. But
wouldn't that work even if  it's undefined (I didn't check the Kconfig
language rules)?

So if it _wasn't_ intentional, maybe add a

        depends on CC_IX_xyz

to the 'xyz_VERSION' config options? That would seem to be a bit more
logical to me.

Also, we already had one bug in the compiler detection due to the grep
looking at the wrong lines earlier. Shouldn't we have some sanity
checking of the CC_IS_xyz things?

IOW, maybe we should error out if we see *both* CC_IS_GCC and
CC_IS_CLANG, but also if we see neither?

Other than those small nit-picks, I  really like how it's more
legible, in addition to this part:

 26 files changed, 173 insertions(+), 308 deletions(-)

Thanks,

          Linus

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Linus Torvalds]

On Wed, Jun 13, 2018 at 8:55 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Wed, Jun 13, 2018 at 7:47 AM Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> >
> > Please pull more Kbuild updates.
>
> Pulled. However, I notice a few oddities.

Oh, and one actual bug: "make oldconfig" doesn't work right.

I used to have

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_NONE is not set
  # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_STACKPROTECTOR_AUTO=y

which means that since my compiler supports -fstack-protector-strong,
I should get CONFIG_CC_STACKPROTECTOR_STRONG.

But that's not at all what I get. I get

  CONFIG_HAVE_CC_STACKPROTECTOR=y
  CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
  CONFIG_CC_STACKPROTECTOR=y
  # CONFIG_CC_STACKPROTECTOR_STRONG is not set
  CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

ie CONFIG_CC_STACKPROTECTOR_STRONG basically went away.

The reason for that is that it takes the *old* value of
CONFIG_CC_STACKPROTECTOR_STRONG, which was "no", but that's wrong.

The meaning of the config option has changed, but it took the default
from the old meaning, and decided that I shouldn't get strong stack
protection any more.

This is a pretty dangerous silent change.

               Linus

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Linus Torvalds]

On Wed, Jun 13, 2018 at 9:03 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> This is a pretty dangerous silent change.

I've merged it despite this, but I think we need to revisit the whole
issue. Possibly by just renaming that option, so that people _see_ the
change and get asked about it.

              Linus

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Masahiro Yamada]

Hi Linus,

2018-06-14 1:03 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Wed, Jun 13, 2018 at 8:55 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>>
>> On Wed, Jun 13, 2018 at 7:47 AM Masahiro Yamada
>> <yamada.masahiro@socionext.com> wrote:
>> >
>> > Please pull more Kbuild updates.
>>
>> Pulled. However, I notice a few oddities.
>
> Oh, and one actual bug: "make oldconfig" doesn't work right.
>
> I used to have
>
>   CONFIG_HAVE_CC_STACKPROTECTOR=y
>   # CONFIG_CC_STACKPROTECTOR_NONE is not set
>   # CONFIG_CC_STACKPROTECTOR_REGULAR is not set
>   # CONFIG_CC_STACKPROTECTOR_STRONG is not set
>   CONFIG_CC_STACKPROTECTOR_AUTO=y
>
> which means that since my compiler supports -fstack-protector-strong,
> I should get CONFIG_CC_STACKPROTECTOR_STRONG.
>
> But that's not at all what I get. I get
>
>   CONFIG_HAVE_CC_STACKPROTECTOR=y
>   CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
>   CONFIG_CC_STACKPROTECTOR=y
>   # CONFIG_CC_STACKPROTECTOR_STRONG is not set
>   CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
>
> ie CONFIG_CC_STACKPROTECTOR_STRONG basically went away.
>
> The reason for that is that it takes the *old* value of
> CONFIG_CC_STACKPROTECTOR_STRONG, which was "no", but that's wrong.
>
> The meaning of the config option has changed, but it took the default
> from the old meaning, and decided that I shouldn't get strong stack
> protection any more.
>
> This is a pretty dangerous silent change.
>
>                Linus


Sorry, I did not notice this case.


I cannot come up with a name better than CC_STACKPROTECTOR_STRONG.


Another solution might be,
to add _AUTO back again for the backward-compatibility.


config CC_STACKPROTECTOR_AUTO
       bool "Stack Protector Auto (backward compatibility)"
       select CC_STACKPROTECTOR_STRONG if $(cc-option,-fstack-protector-strong)
       select CC_STACKPROTECTOR if $(cc-option,-fstack-protector)
       depends on HAVE_CC_STACKPROTECTOR
       help
         This option is here to not break "make oldconfig". If the old .config
         file enabled CC_STACKPROTECTOR_AUTO, CC_STACKPROTECTOR_STRONG should
         be enabled when compiler supports it.
         This will be removed after v4.19.



If a user previously chose _AUTO
and the compiler supports -fstack-protector-strong,
CC_STACKPROTECTOR_STRONG is forcibly enabled.

Of course, this is ugly.
I do not want to carry it for a long time
even if we decide this is necessary.

-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Linus Torvalds]

On Wed, Jun 13, 2018 at 10:29 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> I cannot come up with a name better than CC_STACKPROTECTOR_STRONG.

How about just calling it STACKPROTETOR_STRONG and leaving it at that?

Make the "CC_HAVE_xyz" model for compiler feature tests, but when
actually picking an actual option, it's not really about the compiler
any more, except in the sense that it depends on it.

I guess we could leave the CC_STACKPROTECTOR option as-is, just
because it apparently has a lot of small uses in actual code too, but
there is absolutely nothing that uses CONFIG_CC_STACKPROTECTOR_STRONG
outside of the actual compiler option choice (and config files)

                Linus

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Masahiro Yamada]

Hi Linus,

2018-06-14 2:49 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Wed, Jun 13, 2018 at 10:29 AM Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>>
>> I cannot come up with a name better than CC_STACKPROTECTOR_STRONG.
>
> How about just calling it STACKPROTETOR_STRONG and leaving it at that?

Good idea!

> Make the "CC_HAVE_xyz" model for compiler feature tests, but when
> actually picking an actual option, it's not really about the compiler
> any more, except in the sense that it depends on it.

I agree.

I just respected the original naming,
but CC_ is not sensible any more.


> I guess we could leave the CC_STACKPROTECTOR option as-is, just
> because it apparently has a lot of small uses in actual code too, but
> there is absolutely nothing that uses CONFIG_CC_STACKPROTECTOR_STRONG
> outside of the actual compiler option choice (and config files)

I agree to rename CC_STACKPROTECTOR_STRONG to STACKPROTECTOR_STRONG.
But, I'd like to rename CC_STACKPROTECTOR to STACKPROTECTOR as well.

I guess 30 lines or so in the C code usage.

Could you run sed directly in your tree?



-- 
Best Regards
Masahiro Yamada

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Linus Torvalds]

On Thu, Jun 14, 2018 at 3:16 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> Could you run sed directly in your tree?

Sure, I did that on the  plane. Now on the ground, pushed out.
Somebody should double- and triple-check it.

            Linus

Re: [GIT PULL] Kbuild updates for 4.18 (2nd round)

[Masahiro Yamada]

Hi Linus,


2018-06-14 15:26 GMT+09:00 Linus Torvalds <torvalds@linux-foundation.org>:
> On Thu, Jun 14, 2018 at 3:16 AM Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>>
>> Could you run sed directly in your tree?
>
> Sure, I did that on the  plane. Now on the ground, pushed out.
> Somebody should double- and triple-check it.
>

I double-checked it.
Yes, renaming is perfect.  Thank you!


However, while I was checking it, I noticed some other issues.

I have sent three patches.
If they look good, could you apply them please?


-- 
Best Regards
Masahiro Yamada