From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 5 Aug 2020 15:03:28 -0400 Subject: [PATCH] log: Allow LOG_DEBUG to always enable log output In-Reply-To: References: <20200727022735.1435481-1-sjg@chromium.org> <20200805121819.GA24776@bill-the-cat> <8708d832-cdc2-9875-2ce1-848c0a8869be@gmx.de> <20200805125609.GL6965@bill-the-cat> <20200805183744.GP6965@bill-the-cat> Message-ID: <20200805190328.GQ6965@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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 > > > >>> > > > >>> 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 > > 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 at gmail.com > > > > Reviewed-by: Nick Desaulniers > > Signed-off-by: Nathan Chancellor > > Signed-off-by: Steven Rostedt (VMware) > > > > 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)) \ _log((enum log_category_t)(_cat), _l, __FILE__, __LINE__, \ __func__, \ pr_fmt(_fmt), ##_args); \ It's not a new warning from clang (We've been on LLVM-10 since February), it's only that the logging code is now being run through it via CI. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: