Re: [PATCH] log: Allow LOG_DEBUG to always enable log output

5 Aug 2020

On Wed, Aug 05, 2020 at 09:08:40PM +0200, Heinrich Schuchardt wrote:
...
Am 5. August 2020 21:03:28 MESZ schrieb Tom Rini trini@konsulko.com:
...
On Wed, Aug 05, 2020 at 12:56:17PM -0600, Simon Glass wrote:
...
Hi Tom,
On Wed, 5 Aug 2020 at 12:37, Tom Rini trini@konsulko.com wrote:
...
On Wed, Aug 05, 2020 at 08:31:55PM +0200, Heinrich Schuchardt
wrote:
...
...
...
On 05.08.20 14:56, Tom Rini wrote:
...
On Wed, Aug 05, 2020 at 02:54:05PM +0200, Heinrich Schuchardt
wrote:
...
...
...
...
> On 05.08.20 14:18, Tom Rini wrote:
>> On Sun, Jul 26, 2020 at 08:27:35PM -0600, Simon Glass wrote:
>>
>>> At present if CONFIG_LOG enabled, putting LOG_DEBUG at the
top of a file
...
...
...
...
>>> (before log.h inclusion) causes _log() to be executed for
every log()
...
...
...
...
>>> call, regardless of the build- or run-time logging level.
>>>
>>> However there is no guarantee that the log record will
actually be
...
...
...
...
>>> displayed. If the current log level is lower than LOGL_DEBUG
then it will
...
...
...
...
>>> not be.
>>>
>>> Add a way to signal that the log record should always be
displayed and
...
...
...
...
>>> update log_passes_filters() to handle this.
>>>
>>> Signed-off-by: Simon Glass sjg@chromium.org
>>
>> This exposes an underlying problem with LOG and clang I
believe:
...
...
...
...
>> https://gitlab.denx.de/u-boot/u-boot/-/jobs/135789
>>
>
> include/log.h:147:44: note: expanded from macro 'log'
>         if (CONFIG_IS_ENABLED(LOG) && (_LOG_DEBUG || _l <=
> _LOG_MAX_LEVEL)) \
>                                                   ^
> drivers/misc/p2sb_emul.c:197:10: error: converting the enum
constant to
...
...
...
...
> a boolean [-Werror,-Wint-in-bool-context]
>
> This seems to be a Clang bug. _LOG_DEBUG is not an enum:
>
> #if CONFIG_IS_ENABLED(LOG)
> #ifdef LOG_DEBUG
> #define _LOG_DEBUG      1
> #else
> #define _LOG_DEBUG      0
> #endif
>
> So there seems to be a bug in the Clang you used.
>
> Compiling with clang on Debian Bullseye does not show the
problem:
...
...
...
...
>
> make HOSTCC=clang sandbox_defconfig
> make HOSTCC=clang CC=clang -j8
>
> clang version 9.0.1-13
> LLVM version 9.0.1
>
> Which Clang version did you use?
>
> This is the change that added the test:
> https://reviews.llvm.org/D63082
>
> -Wint-in-bool-context seems to be new in Clang 10.
>
> All over the U-Boot code we assume that a non-zero integer is
true. Do
...
...
...
...
> we really want to enable -Wint-in-bool-context?
I'm using the official Clang 10 stable builds.
Do you really want to forbid using integers as booleans
(-Wint-in-bool-context)?
So, interesting.  The Linux kernel isn't disabling this warning.
It's
...
...
mentioned in two commits, one of which is "clang found a bug here",
of
...
...
which this is not the case.  The other is more like ours:
commit 968e5170939662341242812b9c82ef51cf140a33
Author: Nathan Chancellor natechancellor@gmail.com
Date:   Thu Sep 26 09:22:59 2019 -0700
tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN

macro
...
...
After r372664 in clang, the IF_ASSIGN macro causes a couple

hundred
...
...
warnings along the lines of:

kernel/trace/trace_output.c:1331:2: warning: converting the

enum
...
...
constant to a boolean [-Wint-in-bool-context]
kernel/trace/trace.h:409:3: note: expanded from macro
'trace_assign_type'
                IF_ASSIGN(var, ent, struct

ftrace_graph_ret_entry,
...
...
                ^
kernel/trace/trace.h:371:14: note: expanded from macro

'IF_ASSIGN'
...
...
                WARN_ON(id && (entry)->type != id);     \
                           ^
264 warnings generated.

This warning can catch issues with constructs like:

    if (state == A || B)

where the developer really meant:

    if (state == A || state == B)

This is currently the only occurrence of the warning in the

kernel
...
...
tree across defconfig, allyesconfig, allmodconfig for arm32,

arm64,
...
...
and x86_64. Add the implicit '!= 0' to the WARN_ON statement to

fix
...
...
the warnings and find potential issues in the future.

Link:

https://github.com/llvm/llvm-project/commit/28b38c277a2941e9e891b2db30652cfd...
...
...
Link: https://github.com/ClangBuiltLinux/linux/issues/686
Link:

http://lkml.kernel.org/r/20190926162258.466321-1-natechancellor@gmail.com
...
...
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>


Which is like our case, and reworking the test to be explicit.  I
lean
...
...
towards that.
Oh dear I really want to vote against that.
if (x)
should allow C to consider x to be a boolean. I am hitting this in
Zephyr and feels like it is undoing a long-standing C feature, with
major disruption, for no benefit I can detect.
Hopefully I am misunderstanding what -Wint-in-bool-context means, and
it just applies to enums?
Yes, it's not the simple case, it's the complex case as noted in the
kernel commit message.  Our change I believe would be:

diff --git a/include/log.h b/include/log.h
index 2859ce1f2e72..91ca2e0523f7 100644
--- a/include/log.h
+++ b/include/log.h
@@ -141,7 +141,7 @@ static inline int _log_nop(enum log_category_t cat,
enum log_level_t level,
/* Emit a log record if the level is less that the maximum */
#define log(_cat, _level, _fmt, _args...) ({ \
   int _l = _level; \

if (CONFIG_IS_ENABLED(LOG) && (_l <= _LOG_MAX_LEVEL || _LOG_DEBUG)) \


if (CONFIG_IS_ENABLED(LOG) && (_l <= _LOG_MAX_LEVEL || _LOG_DEBUG ==

1)) \
Why wouldn't we define _LOG_DEBUG as true or false? Shouldn't clang know that true is boolean?
Because I didn't think of that instead, mainly.
-- 
Tom

    