On Fri, Apr 05, 2019 at 06:05:50PM +0200, Luis Ressel wrote:
On Fri, Apr 05, 2019 at 09:39:26AM -0500, Josh Poimboeuf wrote:
Hm, I would actually argue the reverse. Warnings are generally bad and -Werror is useful for ensuring that we don't have any. For warnings that don't provide value, we just disable those individual warnings.
Sure, during development it's an excellent idea to investigate compiler warnings, and -Werror can be useful for that. But the Linux kernel is built by countless users in wildly varying environments, and it's almost a given that someone will use a compiler that'll complain about a valid part of your code whose style it considers bad.
Maybe so, but objtool only supports two compilers: GCC and clang. And only one version of libelf ;-)
As an example, the warning that's breaking the build for me is -Wundef complaining about several "#if UNDEFINED_IDENTIFIER" constructs in the libelf headers. (I agree with gcc in considering this bad style, but it's perfectly valid C, and there probably wasn't a warning about it back when this header was written.)
I consider that a good thing, because I *want* the build to be broken when somebody uses a bad version of libelf. A patch to produce a more useful error message (e.g., "bad version of libelf") would be welcome of course.
If/when we get to the point where there's a valid use case for warnings in the objtool build, I would consider this patch. But we don't seem to be there yet.