linux-kernel - Re: [PATCH] kbuild, LLVMLinux: Add -Werror to cc-option to support clang

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: <5423128D.8070708@converseincode.com>
Date:	Wed, 24 Sep 2014 11:50:53 -0700
From:	Behan Webster <behanw@...verseincode.com>
To:	Michal Marek <mmarek@...e.cz>
CC:	ak@...ux.intel.com, yamada.m@...panasonic.com, hpa@...ux.intel.com,
	linux-kernel@...r.kernel.org, sam@...nborg.org,
	Mark Charlebois <charlebm@...il.com>
Subject: Re: [PATCH] kbuild, LLVMLinux: Add -Werror to cc-option to support
 clang

On 09/24/14 05:07, Michal Marek wrote:
> On 2014-09-23 21:28, behanw@...verseincode.com wrote:
>> From: Mark Charlebois <charlebm@...il.com>
>>
>> Clang will warn about unknown warnings but will not return false
> You mean unknown options, right?
2 kinds of options: flags and warnings. clang used to merely warn about 
unused/unsupported flags/warnings. It now returns errors for unknown 
flags, but not warnings (unless you specify -Werror).

The issue is that a lot of existing projects which use clang expect the 
former behaviour (I agree that makes no sense, but there you go).

>> unless -Werror is set. GCC will return false if an unknown
>> warning is passed.
>>
>> Adding -Werror make both compiler behave the same.
> Can you please limit it to the clang case? Add an internal variable that
> either contains -Werror or nothing, depending on the compiler.
I can do that. Will fix.

>   What I
> fear is that if we use -Werror unconditionally and the user (or some
> automated build system) decides to add some silly option to KCFLAGS, we
> will get silent failures in the cc-option tests.
A valid concern for sure.

> BTW, is there a chance that this would be fixed in some later clang
> version? Accepting unknown commandline options is a rather unusual
> behavior. How are all the ./configure scripts going to cope with it?
Again, clang does error out on unknown compiler flags (as opposed to 
warnings).

Getting clang to error on unused flags wasn't trivial (this change broke 
a lot of builds apparently). Fortunately we weren't the only ones who 
wanted it to behave like gcc in this case. I think it's going to be 
*much* harder to do the same for warnings. The argument given by 
supporters of the current situation is that if a warning isn't 
supported, why break the build? *sigh*

The LLVMLinux project is pushing hard to fix these sorts of things in 
clang, but some changes are more likely than others.

Thanks,

Behan

-- 
Behan Webster
behanw@...verseincode.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/