lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200610063715.v2qrqvwtegdxdwzl@google.com>
Date:   Tue, 9 Jun 2020 23:37:15 -0700
From:   Fangrui Song <maskray@...gle.com>
To:     Arvind Sankar <nivedita@...m.mit.edu>
Cc:     Rong Chen <rong.a.chen@...el.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        kernel test robot <lkp@...el.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        kbuild-all@...ts.01.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [kbuild-all] Re: gcc-5: error: -gz is not supported in this
 configuration

> But if that gcc was originally
> _configured_ with a version of binutils that doesn't support -gz=zlib,

I agree with this theory :)

On 2020-06-10, Arvind Sankar wrote:
>On Tue, Jun 09, 2020 at 11:23:31PM -0400, Arvind Sankar wrote:
>> On Tue, Jun 09, 2020 at 11:12:25PM -0400, Arvind Sankar wrote:
>> > The output of gcc-5 -dumpspecs may also be useful.
>> >
>> > The exact Kconfig check should have been
>> > 	gcc-5 -Werror -gz=zlib -S -x c /dev/null -o /dev/null
>> >
>> > I can't see how that would succeed if the a.c test didn't but maybe just
>> > in case?
>>
>> Oh wait, -S instead of -c. Which means it runs neither the assembler nor
>> the linker, so gcc won't error out. But if that gcc was originally
>> _configured_ with a version of binutils that doesn't support -gz=zlib,
>> it will give an error on -c regardless of whether the runtime binutils
>> would actually support it or not.
>
>I think the below might be better than passing the option via -Wa, since
>gcc will translate -gz=zlib into the right assembler option anyway, and
>it will also generate an error if the compiler driver was misconfigured
>and won't support the option even if the rest of the toolchain does,
>fixing the config dependency.
>
>Unless this doesn't work with Clang?

Clang>=6 supports -gz=zlib

>Alternatively (or even in addition), we should redefine cc-option to use
>-c, it uses -S in the Kconfig version, apparently for speed, but -c in
>the Kbuild version.

Unifying cc-option in scripts/Kbuild.include & scripts/Kconfig.include
sounds good.

>diff --git a/Makefile b/Makefile
>index 839f9fee22cb..cb29e56f227a 100644
>--- a/Makefile
>+++ b/Makefile
>@@ -842,7 +842,7 @@ endif
>
> ifdef CONFIG_DEBUG_INFO_COMPRESSED
> DEBUG_CFLAGS	+= -gz=zlib
>-KBUILD_AFLAGS	+= -Wa,--compress-debug-sections=zlib
>+KBUILD_AFLAGS	+= -gz=zlib
> KBUILD_LDFLAGS	+= --compress-debug-sections=zlib
> endif
>
>diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
>index cb98741601bd..94ce36be470c 100644
>--- a/lib/Kconfig.debug
>+++ b/lib/Kconfig.debug
>@@ -229,7 +229,7 @@ config DEBUG_INFO_COMPRESSED
> 	bool "Compressed debugging information"
> 	depends on DEBUG_INFO
> 	depends on $(cc-option,-gz=zlib)
>-	depends on $(as-option,-Wa$(comma)--compress-debug-sections=zlib)
>+	depends on $(as-option,-gz=zlib)
> 	depends on $(ld-option,--compress-debug-sections=zlib)
> 	help
> 	  Compress the debug information using zlib.  Requires GCC 5.0+ or Clang

This patch looks good.

(clang cc1as only supports(hardcodes) a limited number of -Wa, options
(it parses the options by itself, rather than delegating to GNU as like
GCC). If there is a compiler driver option, that is usually preferable)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ