Re: [mark:arm64/kcsan 11/13] ld.lld: error: undefined symbol: __tsan_atomic64_fetch_add
From: Marco Elver
Date: Thu Sep 30 2021 - 01:47:24 EST
On Thu, Sep 30, 2021 at 05:48AM +0800, kernel test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/kcsan
> head: 4fe9d6c2ef85257d80291086e4514eaaebd3504e
> commit: f5bc7f69b328f00a6accd9a11f5981d2d0c11cb5 [11/13] kcsan: remove atomic builtin support
> config: x86_64-randconfig-a011-20210929 (attached as .config)
> compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project dc6e8dfdfe7efecfda318d43a06fae18b40eb498)
> reproduce (this is a W=1 build):
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?id=f5bc7f69b328f00a6accd9a11f5981d2d0c11cb5
> git remote add mark https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
> git fetch --no-tags mark arm64/kcsan
> git checkout f5bc7f69b328f00a6accd9a11f5981d2d0c11cb5
> # save the attached .config to linux build tree
> mkdir build_dir
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@xxxxxxxxx>
>
> All errors (new ones prefixed by >>):
>
> >> ld.lld: error: undefined symbol: __tsan_atomic64_fetch_add
> >>> referenced by initcall.h:10 (include/trace/events/initcall.h:10)
> >>> main.o:(__traceiter_initcall_level) in archive init/built-in.a
> >>> referenced by initcall.h:10 (include/trace/events/initcall.h:10)
> >>> main.o:(__traceiter_initcall_level) in archive init/built-in.a
> >>> referenced by initcall.h:10 (include/trace/events/initcall.h:10)
> >>> main.o:(__traceiter_initcall_level) in archive init/built-in.a
> >>> referenced 744943 more times
This was another reason why I added the __tsan_atomic instrumentation
calls -- to avoid chasing the odd driver or however this happened using
builtin atomics and the blame always falling on KCSAN. ;-)
This happened more than once, and I just got frustrated and added them,
also in preparation of other odd arches wanting it. I think KCSAN isn't
meant to be the do-not-use-atomic-builtins linter.
If you can somehow keep them, I would prefer that, just to avoid going
back to a world where I have to chase the odd builtin atomic user after
they broke the KCSAN build.
Would a $(call cc-option,-mno-outline-atomics) help?
--- a/kernel/kcsan/Makefile
+++ b/kernel/kcsan/Makefile
@@ -8,7 +8,8 @@ CFLAGS_REMOVE_debugfs.o = $(CC_FLAGS_FTRACE)
CFLAGS_REMOVE_report.o = $(CC_FLAGS_FTRACE)
CFLAGS_core.o := $(call cc-option,-fno-conserve-stack) \
- -fno-stack-protector -DDISABLE_BRANCH_PROFILING
+ -fno-stack-protector -DDISABLE_BRANCH_PROFILING \
+ $(call cc-option,-mno-outline-atomics)
obj-y := core.o debugfs.o report.o
obj-$(CONFIG_KCSAN_SELFTEST) += selftest.o
A quick test with a compiler version which generated outline
atomics suggests that this works.
Thanks,
-- Marco