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

[Tom Rini]

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 at 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 at 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/28b38c277a2941e9e891b2db30652cfd962f070b
    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 at google.com>
    Signed-off-by: Nathan Chancellor <natechancellor at gmail.com>
    Signed-off-by: Steven Rostedt (VMware) <rostedt at goodmis.org>

Which is like our case, and reworking the test to be explicit.  I lean
towards that.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200805/0edf6d54/attachment.sig>