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

Wed Aug 5 21:32:02 CEST 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 at 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 at 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 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.
> >> 
> >> 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
-------------- 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/87489458/attachment.sig>