kees
All 83 comments
This is now broken upstream as of:
e501ce957a786ecd076ea0cfb10b114e6e4d0f40
"x86: Force asm-goto"
nickdesaulniers
on 3 Apr 2018
nickdesaulniers
on 19 Apr 2018
FWIW reverting d0266046ad54e0c964941364cd82a0d0478ce286 and e501ce957a786ecd076ea0cfb10b114e6e4d0f40 upstream can help to work around this problem.
ramosian-glider
on 8 May 2018
Looks like only "x86: Force asm-goto" needs to be reverted.
commit b1ae32dbab50ed19cfc16d225b0fb0114fb13025
"x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation"
Workaround for the sake of BPF compilation which utilizes kernel
headers, but clang does not support ASM GOTO and fails the build.
Fixes: d0266046ad54 ("x86: Remove FAST_FEATURE_TESTS")
https://git.kernel.org/linus/b1ae32dbab50ed19cfc16d225b0fb0114fb13025
dileks
on 24 May 2018
For a clean revert, I now need:
b1ae32dbab5 d026604 8438ee76b e501ce9
nickdesaulniers
on 4 Jun 2018
It's a bit annoying with all these x86/asm-goto warnings. What about?
0001-x86-clang-does-not-support-asm-goto.txt
This patch is on top of Linux v4.17.
dileks
on 8 Jun 2018
Is it possible to allow patch as file-type for attaching files?
dileks
on 8 Jun 2018
Do you think just disabling the asm-goto check won't lead to a miscompiled kernel?
ramosian-glider
on 9 Jul 2018
No, I can boot into bare metal with my patch and it reduces the number of warnings to 7 (2 before depmod is invoked).
dileks
on 31 Jul 2018
As Clang does not support asm-goto how has CONFIG_JUMP_LABEL Kconfig to be set?
Impact?
FYI: I could build and boot with CONFIG_JUMP_LABEL=y.
[1] https://stackoverflow.com/questions/18863363/trying-to-port-gcc-specific-asm-goto-to-clang
dileks
on 2 Aug 2018
My current fix is here (to be applied against mainline linux sources):
diff --git a/Makefile b/Makefile
index 19948e5..cd3c029 100644
--- a/Makefile
+++ b/Makefile
@@ -963,7 +963,7 @@ ifdef CONFIG_STACK_VALIDATION
objtool_target := tools/objtool FORCE
else
ifdef CONFIG_UNWINDER_ORC
- $(error "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
+ $(warning "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
else
$(warning "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
endif
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 8f6e7eb..125f129 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -175,6 +175,11 @@ ifdef CONFIG_FUNCTION_GRAPH_TRACER
endif
endif
+ifndef CC_HAVE_ASM_GOTO
+ $(warning Compiler lacks asm-goto support.)
+ KBUILD_CFLAGS += "-D __BPF_TRACING__"
+endif
+
ifeq ($(ACCUMULATE_OUTGOING_ARGS), 1)
# This compiler flag is not supported by Clang:
KBUILD_CFLAGS += $(call cc-option,-maccumulate-outgoing-args,)
@@ -300,7 +305,6 @@ archprepare: checkbin
checkbin:
ifndef CC_HAVE_ASM_GOTO
@echo Compiler lacks asm-goto support.
- @exit 1
endif
archclean:
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 28764da..2033ac0 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -38,6 +38,11 @@ KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
+ifndef CC_HAVE_ASM_GOTO
+ $(warning Compiler lacks asm-goto support.)
+ KBUILD_CFLAGS += "-D __BPF_TRACING__"
+endif
+
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
GCOV_PROFILE := n
UBSAN_SANITIZE :=n
For some reason make thinks CONFIG_UNWINDER_ORC is set even though I have # CONFIG_UNWINDER_ORC is not set in my config, so I also changed this error to warning.
tpimh
on 6 Sep 2018
With the following patch now in Linus tree, I updated my patch:
commit 829fe4aa9ac16417a904ad1de1307de906854bcf
x86: Allow generating user-space headers without a compiler
What BPF Kconfig settings for arch/x86 require KBUILD_CFLAGS += "-D __BPF_TRACING__"?
If really needed: Isn't it enough to place this in arch/x86/Makefile only?
And the warning should have a meaningful text (XXX: Workaround for BPF when using clang compiler).
I have added a note to the LLVM bug-#.
Just as side-note: This reduces to simply 1 (in words one) warning.
dileks
on 6 Sep 2018
Just saw Nick's commit "include/linux/compiler*.h: add version detection to asm_volatile_goto" in Linux-next.
dileks
on 19 Sep 2018
@nickdesaulniers Any progress in case of Linux/x86 asm-goto support for LLVM/Clang?
dileks
on 22 Oct 2018
Prototype patch for LLVM: https://reviews.llvm.org/D53765 (IIRC, there should be a Clang patch, too. But there's little point posting it since the LLVM patches will probably undergo iteration before landing. Usually new features that require changes to LLVM land in LLVM first, then get a Clang patch added). Alexander has been driving the implementation, and I've been help test behind the scenes.
nickdesaulniers
on 27 Oct 2018
Can please someone comment on [1]...
"[PATCH] jump_label: move 'asm goto' support test to Kconfig"
...and I asked it here in this thread (with weblink in [2]) the correlation between...
x86/asm-goto support and CONFIG_JUMP_LABEL settings especially when using clang-7/clang-8.
All my recent kernel experiments have...
/boot/config-4.19.12-1-amd64-cbl:CONFIG_JUMP_LABEL=y
/boot/config-4.19.12-1-amd64-cbl:CONFIG_HAVE_ARCH_JUMP_LABEL=y
/boot/config-4.20.0-1-amd64-cbl:CONFIG_JUMP_LABEL=y
/boot/config-4.20.0-1-amd64-cbl:CONFIG_HAVE_ARCH_JUMP_LABEL=y
/boot/config-4.20.0-1-amd64-cbl:CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y
What happens when I set CONFIG_JUMP_LABEL=n?
Digging into include/linux/jump_label.hin Linus master Git says:
#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_JUMP_LABEL)
# define HAVE_JUMP_LABEL
#endif
UPDATE: Added WebLink to Patch in [3].
UPDATE-2: Added snippet from include/linux/jump_label.h file.
[1] https://marc.info/?l=linux-kbuild&m=154618304123859&w=2
[2] https://stackoverflow.com/questions/18863363/trying-to-port-gcc-specific-asm-goto-to-clang
[3] https://lore.kernel.org/patchwork/patch/1028282/
dileks
on 31 Dec 2018
That patch should result in no functional change. Masahiro is just combining CONFIG_JUMP_LABEL and HAVE_JUMP_LABEL. Even though you have CONFIG_JUMP_LABEL=y in your config, you are not actually using it because everything depends on HAVE_JUMP_LABEL, which won't be set due to lack of asm goto support.
nathanchance
on 31 Dec 2018
That patch of Mashiro looks correct to me.
But being able to set CONFIG_JUMP_LABEL=y which has no effect is simply confusing and has to be prohibited in earlier Linux kernel versions or marked BROKEN when using a compiler which has no asm-goto support. And the correlation/dependency has to be documented more clearly, for example in the Kconfig help text.
[ arch/Kconfig ]
config JUMP_LABEL
bool "Optimize very unlikely/likely branches"
depends on HAVE_ARCH_JUMP_LABEL
help
This option enables a transparent branch optimization that
makes certain almost-always-true or almost-always-false branch
conditions even cheaper to execute within the kernel.
Certain performance-sensitive kernel code, such as trace points,
scheduler functionality, networking code and KVM have such
branches and include support for this optimization technique.
***
If it is detected that the compiler has support for "asm goto",
the kernel will compile such branches with just a nop
instruction. When the condition flag is toggled to true, the
nop will be converted to a jump instruction to execute the
conditional block of instructions.
***
This technique lowers overhead and stress on the branch prediction
of the processor and generally makes the kernel faster. The update
of the condition is slower, but those are always very rare.
( On 32-bit x86, the necessary options added to the compiler
flags may increase the size of the kernel slightly. )
UPDATE: Add Kconfig help text from arch/Kconfig.
dileks
on 2 Jan 2019
But being able to set CONFIG_JUMP_LABEL=y which has no effect is simply confusing
Exactly why Masahiro's patch exists.
has to be prohibited in earlier Linux kernel versions
I feel like you'll have a hard time convincing upstream maintainers that this is a bug worthy of stable inclusion. I don't personally think it is, given that this issue has been present since jump label's introduction in commit bf5438fca295 ("jump label: Base patch for jump label") in 2010.
marked BROKEN when using a compiler which has no asm-goto support
Which isn't possible without the Kconfig rewrite in 4.18 (only way that Masahiro's patch works), meaning that 4.19 is the only branch where a backport could accurately be done.
nathanchance
on 2 Jan 2019
Unfortunately, we'll now need to revert https://github.com/ClangBuiltLinux/linux/commit/4a789213c9a54c8b618924d3421e56e98df8a447 and https://github.com/ClangBuiltLinux/linux/commit/a959dc88f9c8900296ccf13e2f3e1cbc555a8917 to get the kernel building...
https://travis-ci.com/ClangBuiltLinux/continuous-integration/jobs/168398641
nathanchance
on 5 Jan 2019
Sigh didn't realize that commits can close issues across repos...
nathanchance
on 7 Jan 2019
From #llvm:
14:23 < ctopper> chandlerc: i've been asked to look at asm-goto
Which is cool because ctopper is one of the most active LLVM contributors from Intel.
nickdesaulniers
on 11 Jan 2019
ctopper has published the clang patch, and rebased both.
Last time I had tested these, there was a bug in certain patterns (complicated case sent to ctopper), and then we ran into #3 .
nickdesaulniers
on 11 Jan 2019
Yeah I can at least start an x86 defconfig build on torvalds/linux with those two patches but it doesn't get far...
In file included from /home/nathan/cbl/linux-next/arch/x86/kernel/cpu/mtrr/generic.c:9:
In file included from /home/nathan/cbl/linux-next/include/linux/io.h:25:
In file included from /home/nathan/cbl/linux-next/arch/x86/include/asm/io.h:383:
In file included from /home/nathan/cbl/linux-next/include/asm-generic/io.h:894:
In file included from /home/nathan/cbl/linux-next/include/linux/vmalloc.h:5:
In file included from /home/nathan/cbl/linux-next/include/linux/spinlock.h:51:
In file included from /home/nathan/cbl/linux-next/include/linux/preempt.h:78:
In file included from /home/nathan/cbl/linux-next/arch/x86/include/asm/preempt.h:7:
In file included from /home/nathan/cbl/linux-next/include/linux/thread_info.h:38:
In file included from /home/nathan/cbl/linux-next/arch/x86/include/asm/thread_info.h:53:
/home/nathan/cbl/linux-next/arch/x86/include/asm/cpufeature.h:164:20: error: invalid operand for inline asm constraint 'i'
asm_volatile_goto("1: jmp 6f\n"
^
2 errors generated.
make[5]: *** [/home/nathan/cbl/linux-next/scripts/Makefile.build:277: arch/x86/kernel/cpu/mtrr/generic.o] Error 1
make[5]: *** Waiting for unfinished jobs....
make[4]: *** [/home/nathan/cbl/linux-next/scripts/Makefile.build:492: arch/x86/kernel/cpu/mtrr] Error 2
In file included from /home/nathan/cbl/linux-next/arch/x86/kernel/cpu/mce/amd.c:12:
In file included from /home/nathan/cbl/linux-next/include/linux/interrupt.h:8:
In file included from /home/nathan/cbl/linux-next/include/linux/cpumask.h:12:
In file included from /home/nathan/cbl/linux-next/include/linux/bitmap.h:9:
In file included from /home/nathan/cbl/linux-next/include/linux/string.h:20:
In file included from /home/nathan/cbl/linux-next/arch/x86/include/asm/string.h:5:
In file included from /home/nathan/cbl/linux-next/arch/x86/include/asm/string_64.h:6:
In file included from /home/nathan/cbl/linux-next/include/linux/jump_label.h:117:
/home/nathan/cbl/linux-next/arch/x86/include/asm/jump_label.h:23:20: error: invalid operand for inline asm constraint 'i'
asm_volatile_goto("1:"
^
1 error generated.
But it's a start! This'd be a good pretense for pushing #3 to get resolved (since there are other places where it matters, like with 32-bit x86 support, as noted by David at the LLVM bug in that issue).
nathanchance
on 11 Jan 2019
With ad2673bdc4e360de2abb4a2522fa3dfc9e4060e2 and the gcov series on top of either torvalds/linux or linux-next and D53765 and D56571 with these build options, I get the following LLVM crash when building x86 allyesconfig:
Stack dump:
0. Program arguments: /tmp/tmp.FV0mZVi91d/bin/clang-8 -cc1 -triple x86_64-unknown-linux-gnu -S -disable-free -disable-llvm-verifier -discard-value-names -main-file-name capi.c -mrelocation-model static -mthread-model posix -fno-delete-null-pointer-checks -mllvm -warn-stack-size=2048 -mdisable-fp-elim -relaxed-aliasing -fmath-errno -masm-verbose -no-integrated-as -mconstructor-aliases -fuse-init-array -mcode-model kernel -target-cpu x86-64 -target-feature +retpoline-indirect-calls -target-feature +retpoline-indirect-branches -target-feature -sse -target-feature -mmx -target-feature -sse2 -target-feature -3dnow -target-feature -avx -target-feature -x87 -target-feature +retpoline-external-thunk -disable-red-zone -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /mnt/build/net/bluetooth/cmtp/capi.gcno -nostdsysteminc -nobuiltininc -resource-dir /tmp/tmp.FV0mZVi91d/lib/clang/8.0.0 -isystem /tmp/tmp.FV0mZVi91d/lib/clang/8.0.0/include -include /home/nathan/cbl/linux-next/include/linux/kconfig.h -include /home/nathan/cbl/linux-next/include/linux/compiler_types.h -I /home/nathan/cbl/linux-next/arch/x86/include -I ./arch/x86/include/generated -I /home/nathan/cbl/linux-next/include -I ./include -I /home/nathan/cbl/linux-next/arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I /home/nathan/cbl/linux-next/include/uapi -I ./include/generated/uapi -I /home/nathan/cbl/linux-next/net/bluetooth/cmtp -I net/bluetooth/cmtp -D __KERNEL__ -D CONFIG_X86_X32_ABI -D CONFIG_AS_CFI=1 -D CONFIG_AS_CFI_SIGNAL_FRAME=1 -D CONFIG_AS_CFI_SECTIONS=1 -D CONFIG_AS_FXSAVEQ=1 -D CONFIG_AS_SSSE3=1 -D CONFIG_AS_AVX=1 -D CONFIG_AS_AVX2=1 -D CONFIG_AS_AVX512=1 -D CONFIG_AS_SHA1_NI=1 -D CONFIG_AS_SHA256_NI=1 -D CC_USING_FENTRY -D KBUILD_BASENAME="capi" -D KBUILD_MODNAME="cmtp" -O2 -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -Werror-implicit-function-declaration -Werror=implicit-int -Wno-format-security -Wno-sign-compare -Wno-format-invalid-specifier -Wno-gnu -Wno-address-of-packed-member -Wno-tautological-compare -Wno-unused-const-variable -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Werror=date-time -Werror=incompatible-pointer-types -Wno-initializer-overrides -Wno-unused-value -Wno-format -Wno-sign-compare -Wno-format-zero-length -Wno-uninitialized -std=gnu89 -fno-dwarf-directory-asm -fdebug-compilation-dir /mnt/build -ferror-limit 19 -fmessage-length 0 -fsanitize-coverage-type=3 -fsanitize-coverage-trace-cmp -fsanitize-coverage-trace-pc -fsanitize=kernel-address -fsanitize-recover=kernel-address -pg -mfentry -fwrapv -stack-protector 2 -mstack-alignment=8 -fwchar-type=short -fno-signed-wchar -fobjc-runtime=gcc -fno-common -fdiagnostics-show-option -vectorize-loops -vectorize-slp -mllvm -asan-mapping-offset=0xdffffc0000000000 -mllvm -asan-globals=1 -mllvm -asan-instrumentation-with-call-threshold=0 -mllvm -asan-stack=1 -mllvm -asan-use-after-scope=1 -o /tmp/capi-360d89.s -x c /home/nathan/cbl/linux-next/net/bluetooth/cmtp/capi.c
1. <eof> parser at end of file
2. Per-module optimization passes
3. Running pass 'CallGraph Pass Manager' on module '/home/nathan/cbl/linux-next/net/bluetooth/cmtp/capi.c'.
4. Running pass 'Combine redundant instructions' on function '@cmtp_application_add'
#0 0x00005612fa5e1e32 PrintStackTraceSignalHandler(void*) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x25b2e32)
#1 0x00005612fa5dfac0 llvm::sys::RunSignalHandlers() (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x25b0ac0)
#2 0x00005612fa5e22c1 SignalHandler(int) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x25b32c1)
#3 0x00007fcf1a7d03c0 __restore_rt (/usr/lib/libpthread.so.0+0x123c0)
#4 0x00005612f9ca787e llvm::isSafeToSpeculativelyExecute(llvm::Value const*, llvm::Instruction const*, llvm::DominatorTree const*) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1c7887e)
#5 0x00005612f9ca70c7 llvm::isValidAssumeForContext(llvm::Instruction const*, llvm::Instruction const*, llvm::DominatorTree const*) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1c780c7)
#6 0x00005612f9cb532e computeKnownBitsFromAssume(llvm::Value const*, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1c8632e)
#7 0x00005612f9ca295a computeKnownBits(llvm::Value const*, llvm::KnownBits&, unsigned int, (anonymous namespace)::Query const&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1c7395a)
#8 0x00005612f9ca1f74 llvm::computeKnownBits(llvm::Value const*, llvm::KnownBits&, llvm::DataLayout const&, unsigned int, llvm::AssumptionCache*, llvm::Instruction const*, llvm::DominatorTree const*, llvm::OptimizationRemarkEmitter*, bool) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1c72f74)
#9 0x00005612fa24b35a llvm::InstCombiner::visitCallInst(llvm::CallInst&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x221c35a)
#10 0x00005612fa21bbc5 llvm::InstCombiner::run() (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x21ecbc5)
#11 0x00005612fa21cf6d combineInstructionsOverFunction(llvm::Function&, llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::DominatorTree&, llvm::OptimizationRemarkEmitter&, bool, llvm::LoopInfo*) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x21edf6d)
#12 0x00005612fa21d33f llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x21ee33f)
#13 0x00005612fa1000b0 llvm::FPPassManager::runOnFunction(llvm::Function&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x20d10b0)
#14 0x00005612f9f08ed7 (anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1ed9ed7)
#15 0x00005612fa1008af llvm::legacy::PassManagerImpl::run(llvm::Module&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x20d18af)
#16 0x00005612fa779541 clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::unique_ptr<llvm::raw_pwrite_stream, std::default_delete<llvm::raw_pwrite_stream> >) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x274a541)
#17 0x00005612fae03b23 clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x2dd4b23)
#18 0x00005612fb97f593 clang::ParseAST(clang::Sema&, bool, bool) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x3950593)
#19 0x00005612fae02c63 clang::CodeGenAction::ExecuteAction() (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x2dd3c63)
#20 0x00005612fad62dc7 clang::FrontendAction::Execute() (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x2d33dc7)
#21 0x00005612faccf868 clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x2ca0868)
#22 0x00005612fadfea10 clang::ExecuteCompilerInvocation(clang::CompilerInstance*) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x2dcfa10)
#23 0x00005612f94c99eb cc1_main(llvm::ArrayRef<char const*>, char const*, void*) (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x149a9eb)
#24 0x00005612f94c7d77 main (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x1498d77)
#25 0x00007fcf1a059223 __libc_start_main (/usr/lib/libc.so.6+0x24223)
#26 0x00005612f94c502e _start (/tmp/tmp.FV0mZVi91d/bin/clang-8+0x149602e)
clang-8: error: unable to execute command: Segmentation fault (core dumped)
clang-8: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 8.0.0 (https://github.com/llvm/llvm-project fb4eed381d2d439f9ab14b7940882903a741aaed)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /tmp/tmp.FV0mZVi91d/bin
clang-8: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang-8: note: diagnostic msg:
********************
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-8: note: diagnostic msg: /tmp/capi-ba6b6d.c
clang-8: note: diagnostic msg: /tmp/capi-ba6b6d.sh
clang-8: note: diagnostic msg:
********************
make[2]: *** [/home/nathan/cbl/linux-next/scripts/Makefile.build:277: net/bluetooth/cmtp/capi.o] Error 254
make[1]: *** [/home/nathan/cbl/linux-next/Makefile:1707: net/bluetooth/cmtp/capi.o] Error 2
make[1]: Leaving directory '/mnt/build'
make: *** [Makefile:152: sub-make] Error 2
Here are the files it mentions in case they are necessary.
I also see a ton of objtool warnings along these lines so I am guessing that there will be some change needed on that side but we can cross that bridge when we come to it:
fs/ceph/mds_client.o: warning: objtool: ceph_send_cap_releases()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: ceph_send_cap_releases()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_do_request()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_do_request()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_init()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_init()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_sync()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_sync()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_handle_mdsmap()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: ceph_mdsc_handle_mdsmap()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: register_session()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: register_session()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: handle_forward()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: handle_forward()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: __unregister_request()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: __unregister_request()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
fs/ceph/mds_client.o: warning: objtool: set_request_path_attr()+0x9: undefined stack state
fs/ceph/mds_client.o: warning: objtool: set_request_path_attr()+0x0: stack state mismatch: cfa1=6+16 cfa2=7+8
Please report the issues on the patch review. Craig will need to look into them.
gwelymernans
on 16 Jan 2019
@gwelymernans Thank you for mentioning my mention on the review, I was at work all day. I'll be sure to note future issues on the review directly.
nathanchance
on 17 Jan 2019
No problem. I realized after I wrote the comment that I could just add the link there and didn't have to wait. :-)
gwelymernans
on 17 Jan 2019
We need to investigate these objtool warnings before asm goto can land.
nickdesaulniers
on 17 Jan 2019
We should probably report it to Josh Poimboeuf, the objtool maintainer, and see what he says, as objtool could need to be updated (GCC updates have required changes). He can usually figure out issues fairly quickly.
I won't be off work for a few hours but I'll test Craig's new revision as soon as I get home.
nathanchance
on 17 Jan 2019
There are a few distinct issues I'm seeing with x86_64 allyesconfig kernel builds that I think we need to sort out, (and will file a few separate bugs to track):
drivers/spi/spidev.o:(__jump_table+0x74): undefined reference to .Ltmp4'
- Is this seen because of asm goto patches or not?
- seems like the base defconfig +
CONFIG_SPI_SPIDEVis not enough to retrigger. - what combo of configs trigger it?
- #320
__compiletime_assert_inarch/x86/kvm/x86.o: In functionguest_cpuid_has'`.
- is a failed static assertion seen at link time.
- Related to asm goto or not?
- #315
__compiletime_assert_inarch/x86/kvm/vmx/vmx.o: In functionguest_cpuid_has'`.
- is a failed static assertion seen at link time.
- Related to asm goto or not?
- #316
- modpost section mismatch
reference from the function test_and_clear_bit() to the variable .init.data:nmi_ipi_mask
- asm goto related or not?
- #317
- MANY repeated objtool validation warnings.
- seems to be pairs of
undefined stack statefollowed bystack state mismatch - #319
- seems to be pairs of
- objtool warning in the form of
special: can't find new instruction
nickdesaulniers
on 17 Jan 2019
Are these all on mainline?
nathanchance
on 17 Jan 2019
Are these all on mainline?
Yes.
Also, glib will benefit from asm goto: https://github.com/GNOME/glib/blob/1ba843b8a0585f20438d5617521f247071c6d94c/glib/gbitlock.c#L181.
nickdesaulniers
on 18 Jan 2019
Are these all on mainline?
Yes.
PEBKAC. was slightly behind mainline. Cleaning up previously filed issues.
nickdesaulniers
on 18 Jan 2019
none of the above issues are observed with gcc-8 and https://github.com/ClangBuiltLinux/linux/commit/0670525ded48caf958b6535d388e6478b6b14a4b :(.
nickdesaulniers
on 18 Jan 2019
@nickdesaulniers @nathanchance
I wanted to give the x86/asm-goto RFC implementation for LLVM/Clang a try.
Here I am on Debian/buster AMD64.
Anyone tested the patches D53765 and D56571 against llvm-toolchain (llvm, clang and compiler-rt in my case) version 8.0.0-rc1?
With which revisions of them?
UPDATE: Applied D53765.id182593.diff and D56571.id181973.diff against 8.0.0rc1.
What do I need on the Linus upstream side?
"WIP: asm goto: x86: convert some __always_inline functions to macros" is mandatory?
UPDATE: WIP patch is required.
Do I need the GCOV patches - with which kernel-config set?
I would prefer to test against Linux v5.0-rc3 or v5.0-rc4 next Monday.
Not sure if I have time this weekend for some testing.
UPDATE: Building against Linux v5.0-rc3+.
[ up to commit c04e2a780caf7073c31c4289c4b7c3d62f9c0130 ("Merge tag 'fsnotify_for_v5.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs") ]
See the above mentioned objtool warnings, too.
Is CONFIG_STACK_VALIDATION=n an option to workaround this?
Any patches for testing from the Linux objtool maintainer?
[1] https://github.com/ClangBuiltLinux/linux/commits/asm_goto
dileks
on 24 Jan 2019
is mandatory?
UPDATE: WIP patch is required.
Unless we get asm goto inlining (inlining of functions containing asm goto) working, which is nice to have but not correctness related. So we'll probably land the patch implementing asm goto, then start on another patch that adds inlining support so that we may drop that out of tree patch.
Do I need the GCOV patches
Only if you want to test the GCOV related configs or allyesconfig.
See the above mentioned objtool warnings, too.
Tracking them in https://github.com/ClangBuiltLinux/linux/issues/319.
Is CONFIG_STACK_VALIDATION=n an option to workaround this?
It's flagging real bugs, and they're warnings not build errors so there's no need to turn that config off.
Any patches for testing from the Linux objtool maintainer?
Josh has been helping me via email understand what objtool is warning about. It's a nice tool; diagnostics could use more polish, but it's been pretty helpful so far.
Thanks for helping test and report bugs!
nickdesaulniers
on 26 Jan 2019
@nickdesaulniers
My setup is now llvm-toolchain-8.0.0rc1 (llvm and clang only, dropped compiler-rt) and applied D53765-id183688.diff and D56571-id181973.diff.
In arch/x86/mm/fault.o I see the following error:
clang-8: /home/sdi/src/llvm-toolchain/llvm/lib/CodeGen/MachineBasicBlock.cpp:1361: llvm::MachineBasicBlock::const_probability_iterator llvm::MachineBasicBlock::getProbabilityIterator(llvm::MachineBasicBlock::const_succ_iterator) const: Assertion `index < Probs.size() && "Not a current successor!"' failed
Attached are the reproducer scripts, my kernel-config and an excerpt of my build-log.
config-5.0.0-rc3-3-amd64-cbl.txt
fault-18bb8b.c.txt
fault-18bb8b.sh.txt
build-log_fault-18bb8b.txt
dileks
on 26 Jan 2019
applied D53765-id183688.diff
The latest version of D53765 is 183714 (contains bug fixes). @dileks Please upgrade the llvm patch you have applied, then file a new/separate issue if you can still repro.
nickdesaulniers
on 26 Jan 2019
With D53765-id183714.diff the error in arch/x86/mm/fault.o is gone.
dileks
on 27 Jan 2019
Static Keys in Linus Git tree has some informations on GCC's asm goto statement, jump labels and statistics.
dileks
on 28 Jan 2019
Address the last round of comments from Chandler. I'll commit this shortly.
dileks
on 8 Feb 2019
https://reviews.llvm.org/D53765 (llvm support for asm goto) has been committed by @topperc ! We still need https://reviews.llvm.org/D56571 (clang support for asm goto), and finally, inlining support to fix a few issues in the kernel.
nickdesaulniers
on 8 Feb 2019
Is it true that inlining support patch doesn't exist yet? I believe it doesn't need a separate issue opened as this one is broad enough to include it too.
tpimh
on 9 Feb 2019
I was able to boot on bare metal...
root@iniza:~# cat /proc/version
Linux version 5.0.0-rc5-4-amd64-cbl-asmgoto ([email protected]@iniza) (clang version 9.0.0 (https://github.com/llvm-mirror/clang.git 1fa8b1fbd40d147ef9fa0fe73fbd44977250989f) (https://github.com/llvm-mirror/llvm.git b9a8dc62465dd5292d9d93e91f3f9ac248a6891e)) #4~buster+dileks1 SMP 2019-02-09
➜ ~ cat /proc/version
Linux version 5.0.0-rc5+ (nick@nick-Blade-Stealth) (clang version 9.0.0 (https://github.com/llvm/llvm-project.git 679910db708aa1575b41ca27bc3a954f3d828c7a)) #25 SMP Sat Feb 9 16:54:36 PST 2019
Is it true that inlining support patch doesn't exist yet?
Correct. I needed https://github.com/ClangBuiltLinux/linux/commit/0670525ded48caf958b6535d388e6478b6b14a4b and https://github.com/ClangBuiltLinux/linux/issues/315#issuecomment-458043298 applied to build.
nickdesaulniers
on 10 Feb 2019
@nickdesaulniers
Great. I have applied the same two patches.
What are your stack-protector and inlining Kconfig settings?
dileks
on 10 Feb 2019
➜ linux git:(asm_goto) ✗ grep STACKP .config
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
➜ linux git:(asm_goto) ✗ grep INLIN .config
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_OPTIMIZE_INLINING=y
OK. I tried with safe settings CONFIG_STACKPROTECTOR_STRONG=n and CONFIG_OPTIMIZE_INLINING=n. Tomorrow i will turn them on and try.
scripts/config -d DRM_AMDGPU -d FCOE -d LIBFCOE -e STACKPROTECTOR_STRONG -e OPTIMIZE_INLINING
I will try with last commits from @topperc in both llvm-git and clang-git.
git log --author="Craig Topper" -1
I have a patch that fixes LLVM so we don't need https://github.com/ClangBuiltLinux/linux/commit/0670525ded48caf958b6535d388e6478b6b14a4b. Will post them tomorrow. I expect them to go through a few rounds of iteration before landing. Building an x86_64 kernel now; then testing arm64; but results so far look promising.
- EDIT *
Crash in llvm::BasicBlock::moveBefore (llvm::LoopRotation) while compiling drivers/char/random.c. Might be a separate bug. Also, it seems that arm64 still doesn't compile. :(
nickdesaulniers
on 11 Feb 2019
I like that cartoon from Futurama.
If you have something for testing, please let me know.
dileks
on 11 Feb 2019
On my Debian/buster AMD64 system I am using the kernel-config from latest 4.20 Debian kernel as a base.
Last weekend I had success (kernel boots on bare metal) with a llvm-toolchain-9 consisting of...
clang.git: 031d8bb68276f35a4a065cdb5944fc0e6a04c4fa (plus D56571.id185911.diff [0])
llvm.git: 5511feb5dbe8f56fb76c626cd9f3c286ab9ff147 (includes asm-goto support)
Caution: Newer Git versions currently produce a compiler crash, see [1].
Applied patches against Linux v5.0-rc6 where [2] and [3] are mandatory for a llvm-toolchain with asm-goto support and [4] if you have CONFIG_FCOE=m|y and CONFIG_LIBFCOE=m|y (independent of asm-goto):
$ git --no-pager log --no-merges --oneline v5.0-rc6..
315564629af6 (for-5.0/scsi-fcoe) fcoe: make use of fip_mode enum complete
aadf16734696 (for-5.0/kvm-x86-cbl-asmgoto) KVM: x86: asm-goto: Workaround CBL issue #315 and #316
0670525ded48 (for-5.0/x86-cbl-asmgoto) WIP: asm goto: x86: convert some __always_inline functions to macros
Unset this Kconfig which is known to be broken (independent of asm-goto) and worked on a patch (for details see [5]):
scripts/config -d DRM_AMDGPU
[0] https://reviews.llvm.org/D56571?id=185911
[1] https://github.com/ClangBuiltLinux/linux/issues/359
[2] https://github.com/ClangBuiltLinux/linux/commit/0670525ded48caf958b6535d388e6478b6b14a4b
[3] https://github.com/ClangBuiltLinux/linux/issues/315
[4] https://github.com/ClangBuiltLinux/linux/issues/151
[5] https://github.com/ClangBuiltLinux/linux/issues/327
dileks
on 11 Feb 2019
x86: https://bugs.llvm.org/show_bug.cgi?id=40722
separate issue for arm64, but I'll edit this post with a link once I have more time to sit and analyze that case more.
nickdesaulniers
on 13 Feb 2019
I am looking for some ideas to test asm-goto support.
I extracted all involved tests for clang out of D56571:
#!/bin/sh
export LANG=C
export LC_ALL=C
cd build
# CBL issue #6 ("support for asm goto")
# https://github.com/ClangBuiltLinux/linux/issues/6
# https://reviews.llvm.org/rL353563 ("Implementation of asm-goto support in LLVM")
# https://reviews.llvm.org/D56571 ("[RFC prototype] Implementation of asm-goto support in clang")
TESTS="$TESTS CodeGen/asm.c"
TESTS="$TESTS CodeGen/inline-asm-mixed-style.c"
TESTS="$TESTS Parser/asm.c"
TESTS="$TESTS Parser/asm.cpp"
TESTS="$TESTS Sema/asm.c"
TESTS="$TESTS Sema/inline-asm-validate-tmpl.cpp"
TESTS="$TESTS Sema/scope-check.c"
TESTS="$TESTS Analysis/asm-goto.cpp"
TESTS="$TESTS CodeGen/asm-goto.c"
TESTS="$TESTS Sema/asm-goto.cpp"
for t in $TESTS ; do ./bin/llvm-lit -v ./tools/clang/test/$t ; done
The Linux-kernel checks via gcc-goto.sh script and sets CONFIG_CC_HAS_ASM_GOTO accordingly.
Any other ideas to test llvm-toolchain and/or Linux-kernel to test before running a full build?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/scripts/gcc-goto.sh
dileks
on 14 Feb 2019
@nickdesaulniers @topperc
D56571 diff 187124 does not cleanly apply against Clang Git.
I would like to test #368 but with a llvm-toolchain with asm-goto support.
Can you ping responsible people? Thanks.
UPDATE: Rebased as D56571 diff 188021
UPDATE: Status asm-goto & asm-flags-outputs https://github.com/ClangBuiltLinux/linux/issues/368#issuecomment-466720360
dileks
on 22 Feb 2019
I have built clang with D56571 patch, but unfortunately was not able to compile asm_goto branch with it. With defconfig I get errors like this:
In file included from init/main.c:103:
./include/trace/events/initcall.h:27:1: error: expected a symbol reference in '.long' directive
TRACE_EVENT(initcall_start,
^
./include/linux/tracepoint.h:534:2: note: expanded from macro 'TRACE_EVENT'
DECLARE_TRACE(name, PARAMS(proto), PARAMS(args))
^
./include/linux/tracepoint.h:398:2: note: expanded from macro 'DECLARE_TRACE'
__DECLARE_TRACE(name, PARAMS(proto), PARAMS(args), \
^
./include/linux/tracepoint.h:237:7: note: expanded from macro '__DECLARE_TRACE'
if (static_key_false(&__tracepoint_##name.key)) \
^
./include/linux/jump_label.h:199:2: note: expanded from macro 'static_key_false'
arch_static_branch(key, false); })
^
./arch/x86/include/asm/jump_label.h:28:17: note: expanded from macro 'arch_static_branch'
_ASM_ALIGN "\n\t" \
^
<inline asm>:4:19: note: instantiated into assembly here
.long 1b - ., "" - .
^
…
3 errors generated.
make[1]: *** [scripts/Makefile.build:277: init/main.o] Error 1
make: *** [Makefile:1041: init] Error 2
Anyone had similar errors before? Did I forget to apply some patches?
tpimh
on 26 Feb 2019
@tpimh
I was able to build Linux v5.0 final with...
llvm-toolchain 9.0.0 (single Git repos not monorepo)
clang-git: 1245e82a9186 ("[X86] Add 'znver2' and 'cascadelake' to the __builtin_cpu_is test.")
D56571: diff 188021
llvm-git: 56d9da61e3c1("[llvm-readobj] Display section names for STT_SECTION symbols.")
lld-git: 9e64abb578e1("[lld][test] Fix tests. llvm-readobj now emits symbol section names.")
Mandatory patches:
KVM: x86: asm-goto: Workaround CBL issue #315 and #316
WIP: asm goto: x86: convert some __always_inline functions to macros
Additional patches:
scsi: fcoe: make use of fip_mode enum complete
Hooray:
Linux version 5.0.0-1-amd64-cbl-asmgoto ([email protected]@iniza) (clang version 9.0.0 (https://github.com/llvm-mirror/clang.git 1245e82a91861a23e67c2ffd18cd3a5bcb69aa63) (https://github.com/llvm-mirror/llvm.git 56d9da61e3c165e839f97bfeffb69d5bf85b361d)) #1~buster+dileks1 SMP 2019-03-04
I think I know what my problem is: I'm trying to use integrated as. Removed this line like it's no big deal:
https://github.com/ClangBuiltLinux/linux/blob/1c163f4c7b3f621efff9b28a47abb36f7378d783/Makefile#L502
It is. And it needs a separate issue (UPD: #413).
tpimh
on 4 Mar 2019
I'm still working on inlining callbr support, but today I fixed a compiler crash in drivers/char/random.c that I hit when testing out the inlining support: https://reviews.llvm.org/D58929. Note that I have not yet published the inlining patch, so this link is quite meaningless now. But, with:
- clang asm goto support
- fix callbr LoopRotate
- my yet to be published patch enabling inlining of callbr
The kernel builds. Unfortunately, it doesn't boot in QEMU :cry: :sob: :disappointed: but maybe we can work out some of the kinks from inlining during code review.
EDIT: hitting this trying to debug in GDB.
nickdesaulniers
on 5 Mar 2019
@nickdesaulniers
What's the status of [1] (which is delaying [2])?
Is it safe for testing with dropping the WIP patch?
Which version (monorepo) do you use for your latest experiments?
[1] https://reviews.llvm.org/D58260
[2] https://reviews.llvm.org/D56571
dileks
on 18 Mar 2019
What's the status of [1] (which is delaying [2])?
This is my number 1 priority right now. Been working through an early boot crash with my patch. WIP
nickdesaulniers
on 25 Mar 2019
I think "compiler-attribute: stop forcing __always_inline to inline marker" patch is worth testing in this context.
UPDATE: [2] "compiler: allow all arches to enable CONFIG_OPTIMIZE_INLINING" (worth testing with CONFIG_OPTIMIZE_INLINING=n).
[1] https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=build-test2&id=a743d841dfd56d04f16245e3698d64997c02c8d7
[2] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/commit/?h=randconfig-5.1&id=589fb47709f1b731135c3becb2b13ec0da6baa7d
dileks
on 28 Mar 2019
Note that with:
- https://reviews.llvm.org/D60208 ("[X86] Extend boolean arguments to
inline-asm according to getBooleanType") - https://reviews.llvm.org/D58260 ("[INLINER] allow inlining of
blockaddresses if sole uses are callbrs") - https://reviews.llvm.org/D56571 ("[RFC prototype] Implementation of
asm-goto support in clang")
I can compile a mainline x86 defconfig Linux kernel and boot it in QEMU.
nickdesaulniers
on 3 Apr 2019
For arm64, it seems that the handling of "i" extended inline assembly constraint is different, too.
https://bugs.llvm.org/show_bug.cgi?id=41402
nickdesaulniers
on 5 Apr 2019
@nickdesaulniers
What was the base (monorepo Git hash) of this success of a story?
dileks
on 5 Apr 2019
Also, for arm64:
- https://reviews.llvm.org/D60428 ("[Aarch64AsmPrinter] support %c output template for global addresses")
What was the base (monorepo Git hash) of this success of a story?
r356064 plus the above patches (1-4).
nickdesaulniers
on 9 Apr 2019
@nickdesaulniers I am trying to test these set of patches but everything aside from x86 is failing. Am I missing something or is this expected right now?
https://gist.github.com/fabfd44f2d18c7b8665370c0950f4004
$ git -C ~/cbl/git/tc-build/llvm-project log --format="%H %s" origin/master.. | cat
09f1c4440db5c8c973515d497bb292b8076d3454 D60887
4e10c281ebaf34ac6e42d11f0efd31cb85f92d46 D60224
32cce9c968d00186afb57360677ee96a3ed66943 D60042
e7477359aeaf920b954b129f26b55e3f7f149988 D58260
cbd4331a94a180196e70f91babc57b3e682dfa25 D56571
pretty sure I tested arm64 defconfig. Recent changes I made to one of the patches may have regressed this...
nickdesaulniers
on 26 Apr 2019
With D56571, D58260, and D61560 applied, I am seeing a crash in certain files on an arm allyesconfig build:
$ make -j$(nproc) ARCH=arm CC=clang CROSS_COMPILE=arm-linux-gnueabi- HOSTCC=clang allyesconfig fs/ceph/inode.o
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
LEX scripts/kconfig/lexer.lex.c
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
YACC scripts/kconfig/parser.tab.c
YACC scripts/kconfig/parser.tab.h
HOSTCC scripts/kconfig/symbol.o
HOSTCC scripts/kconfig/preprocess.o
HOSTCC scripts/kconfig/parser.tab.o
HOSTCC scripts/kconfig/lexer.lex.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --allyesconfig Kconfig
boolean symbol THERMAL tested for 'm'? test forced to 'n'
#
# configuration written to .config
#
SYSHDR arch/arm/include/generated/uapi/asm/unistd-oabi.h
SYSHDR arch/arm/include/generated/uapi/asm/unistd-common.h
SYSHDR arch/arm/include/generated/uapi/asm/unistd-eabi.h
WRAP arch/arm/include/generated/uapi/asm/kvm_para.h
WRAP arch/arm/include/generated/uapi/asm/bitsperlong.h
WRAP arch/arm/include/generated/uapi/asm/errno.h
WRAP arch/arm/include/generated/uapi/asm/bpf_perf_event.h
WRAP arch/arm/include/generated/uapi/asm/ioctl.h
WRAP arch/arm/include/generated/uapi/asm/ipcbuf.h
WRAP arch/arm/include/generated/uapi/asm/msgbuf.h
WRAP arch/arm/include/generated/uapi/asm/param.h
WRAP arch/arm/include/generated/uapi/asm/poll.h
WRAP arch/arm/include/generated/uapi/asm/resource.h
WRAP arch/arm/include/generated/uapi/asm/sembuf.h
WRAP arch/arm/include/generated/uapi/asm/shmbuf.h
WRAP arch/arm/include/generated/uapi/asm/siginfo.h
WRAP arch/arm/include/generated/uapi/asm/socket.h
WRAP arch/arm/include/generated/uapi/asm/sockios.h
WRAP arch/arm/include/generated/uapi/asm/termbits.h
WRAP arch/arm/include/generated/uapi/asm/termios.h
UPD include/generated/uapi/linux/version.h
WRAP arch/arm/include/generated/asm/compat.h
WRAP arch/arm/include/generated/asm/emergency-restart.h
WRAP arch/arm/include/generated/asm/current.h
WRAP arch/arm/include/generated/asm/early_ioremap.h
WRAP arch/arm/include/generated/asm/exec.h
WRAP arch/arm/include/generated/asm/extable.h
WRAP arch/arm/include/generated/asm/irq_regs.h
WRAP arch/arm/include/generated/asm/kdebug.h
WRAP arch/arm/include/generated/asm/local.h
WRAP arch/arm/include/generated/asm/mm-arch-hooks.h
WRAP arch/arm/include/generated/asm/local64.h
WRAP arch/arm/include/generated/asm/mmiowb.h
WRAP arch/arm/include/generated/asm/parport.h
WRAP arch/arm/include/generated/asm/msi.h
WRAP arch/arm/include/generated/asm/preempt.h
WRAP arch/arm/include/generated/asm/seccomp.h
WRAP arch/arm/include/generated/asm/trace_clock.h
WRAP arch/arm/include/generated/asm/serial.h
WRAP arch/arm/include/generated/asm/simd.h
HOSTCC scripts/dtc/dtc.o
HOSTCC scripts/dtc/fstree.o
HOSTCC scripts/dtc/flattree.o
HOSTCC scripts/dtc/data.o
HOSTCC scripts/dtc/livetree.o
HOSTCC scripts/dtc/treesource.o
UPD include/config/kernel.release
HOSTCC scripts/dtc/srcpos.o
HOSTCC scripts/dtc/checks.o
HOSTCC scripts/dtc/util.o
LEX scripts/dtc/dtc-lexer.lex.c
YACC scripts/dtc/dtc-parser.tab.h
YACC scripts/dtc/dtc-parser.tab.c
HOSTCC scripts/dtc/yamltree.o
HOSTCC scripts/dtc/dtc-parser.tab.o
HOSTCC scripts/dtc/dtc-lexer.lex.o
UPD include/generated/utsrelease.h
HOSTLD scripts/dtc/dtc
HOSTCC scripts/bin2c
HOSTCC scripts/kallsyms
HOSTCC scripts/conmakehash
HOSTCC scripts/pnmtologo
HOSTCC scripts/recordmcount
HOSTCC scripts/sortextable
HOSTCC scripts/genksyms/genksyms.o
YACC scripts/genksyms/parse.tab.c
HOSTCC scripts/asn1_compiler
LEX scripts/genksyms/lex.lex.c
YACC scripts/genksyms/parse.tab.h
HOSTCC scripts/sign-file
HOSTCC scripts/extract-cert
HOSTCC scripts/insert-sys-cert
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
HOSTCC scripts/genksyms/lex.lex.o
HOSTCC scripts/genksyms/parse.tab.o
HOSTLD scripts/genksyms/genksyms
SYSNR arch/arm/include/generated/asm/unistd-nr.h
GEN arch/arm/include/generated/asm/mach-types.h
SYSTBL arch/arm/include/generated/calls-eabi.S
SYSTBL arch/arm/include/generated/calls-oabi.S
HOSTCC scripts/mod/mk_elfconfig
CC scripts/mod/devicetable-offsets.s
CC scripts/mod/empty.o
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/sumversion.o
HOSTCC scripts/mod/modpost.o
UPD scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTLD scripts/mod/modpost
CC kernel/bounds.s
CALL scripts/atomic/check-atomics.sh
UPD include/generated/timeconst.h
UPD include/generated/bounds.h
CC arch/arm/kernel/asm-offsets.s
UPD include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
<stdin>:1388:2: warning: syscall open_tree not implemented [-W#warnings]
#warning syscall open_tree not implemented
^
<stdin>:1391:2: warning: syscall move_mount not implemented [-W#warnings]
#warning syscall move_mount not implemented
^
<stdin>:1394:2: warning: syscall fsopen not implemented [-W#warnings]
#warning syscall fsopen not implemented
^
<stdin>:1397:2: warning: syscall fsconfig not implemented [-W#warnings]
#warning syscall fsconfig not implemented
^
<stdin>:1400:2: warning: syscall fsmount not implemented [-W#warnings]
#warning syscall fsmount not implemented
^
<stdin>:1403:2: warning: syscall fspick not implemented [-W#warnings]
#warning syscall fspick not implemented
^
6 warnings generated.
CC fs/ceph/inode.o
/tmp/inode-f30606.s: Assembler messages:
/tmp/inode-f30606.s:3587: Error: bad immediate value for offset (4104)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
make[2]: *** [scripts/Makefile.build:279: fs/ceph/inode.o] Error 1
make[1]: *** [Makefile:1747: fs/ceph/inode.o] Error 2
make: *** [Makefile:325: __build_one_by_one] Error 2
I am attempted to creduce but it's been running for a very long time so no idea if it is going to come to anything conclusive. Without those patches, it doesn't happen (but that doesn't mean it is caused by them, might be exposing another bug that hasn't been visible without asm goto).
nathanchance
on 6 May 2019
Unfortunately, creduce doesn't seem to be fruitful, as I let it run all night and it keeps getting stuck.
These are all of the errors I see with arm allyesconfig before it fully dies: https://gist.github.com/eeaa1401e81b581841503795c295919d
However, the good news is everything else seems to check out with all of the other architectures/builds that I do: https://gist.github.com/5ec94917908f646ce2446c8edc724dc9
$ git log --format="%H %s" origin/master^.. | cat
8b790c56253f867cbb6af8dab044bb6a7f178aab Merge branch 'asm-goto'
d4365d1e118f22043812aed5678df1f3e59ba7a1 D61560
0865d38ea6afdb484a6c76023c4faaabb5537945 D58260
64f3bf0a62666b74debfdd82cb3929f9adf2bec1 D56571
399868df541d0108f8079175043253ffbe04d12c D61201
577c71e143a5fe6a47febec76b59ecc7dccf1320 D60042
987b969babe10ffb85d9f81e7449d005707109eb Fix bug in getCompleteTypeIndex in codeview debug info
Down to 2 patches:
- D60224: [TargetLowering] Extend bool args to inline-asm according to getBooleanType
- D56571: [RFC prototype] Implementation of asm-goto support in clang
I've confirmed that w/ these 2 on top of ToT llvm, I can build+boot:
- x86_64 defconfig (contains CONFIG_RANDOMIZE_BASE)
- x86_64 defconfig + CONFIG_STATIC_KEYS_SELFTEST=y
- arm64 defconfig
- arm64 defconfig + CONFIG_RANDOMIZE_BASE=y
- arm64 defconfig + CONFIG_RANDOMIZE_BASE=y + CONFIG_STATIC_KEYS_SELFTEST=y
- arm multi_v7_defconfig
- arm multi_v7_defconfig + CONFIG_STATIC_KEYS_SELFTEST=y
w/ no warnings or failures.
nickdesaulniers
on 20 May 2019
I've requested LLVM commit access. If that takes too long, I'm happy for anyone to push D60224 on my behalf. :)
kees
on 21 May 2019
I am still seeing those assembler errors on arm32 allyesconfig.
clang location: /home/nathan/cbl/tc-build/build/llvm/stage1/bin/clang
clang version 9.0.0 (git://github.com/llvm/llvm-project e96f23e3c797c5b14d7c719e879639852c7a8789)
Version: 5.2.0-rc1-cbl-next-20190521+
arm:multi_v7_defconfig | Build successful in 3 minutes and 27 seconds | Boot successful
arm:allyesconfig | Build failed in 2 minutes and 15 seconds
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
clang-9: error: assembler command failed with exit code 1 (use -v to see invocation)
arm64:defconfig | Build successful in 4 minutes and 28 seconds | Boot successful
arm64:allyesconfig | Build successful in 16 minutes and 51 seconds
ppc64le:powernv_defconfig | Build successful in 3 minutes and 31 seconds | Boot successful
x86:defconfig | Build successful in 2 minutes and 19 seconds | Boot successful
x86:allyesconfig | Build successful in 20 minutes and 6 seconds
I am going to try and narrow down the config that causes the issues tomorrow.
nathanchance
on 22 May 2019
darn, yes I can reproduce: https://gist.github.com/nickdesaulniers/37ec31896139b032d915b18eb09fc6cc
nickdesaulniers
on 22 May 2019
I've greenlit the clang patch for landing: https://reviews.llvm.org/D56571#1516502
Thanks to @nathanchance for the additional green light: https://github.com/ClangBuiltLinux/linux/issues/490#issuecomment-495736003
nickdesaulniers
on 24 May 2019
nathanchance
on 30 May 2019
And this is why I left this issue open...
https://github.com/llvm/llvm-project/commit/d0f34fd19850c79f8741301c3bfe0312ca24324c
nathanchance
on 30 May 2019
😞😞😞 Is there a thread about the failures? I don't see anything on cfe-dev?
kees
on 30 May 2019
Jennifer pointed me to the LLVM build dashboard and some failures like:
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/6656
kees
on 30 May 2019
Cool.
Does the revert affect x86 arch?
If NO, I would like to test up to...
commit ba2ab1b61589501c54be5e41883a7b6210b43759
"[AST] asm goto labels don't have constraints, don't try to copy them. "
[1] https://github.com/llvm-mirror/clang/commit/ba2ab1b61589501c54be5e41883a7b6210b43759
dileks
on 31 May 2019
Recommitted: https://github.com/llvm/llvm-project/commit/b8fee677bf8e2d6444c556293d6b77fb876654e4
I think this issue can be closed now (and reopened if it is reverted again).
See the asm goto label for the outstanding individual issues.
nathanchance
on 3 Jun 2019
Great!
[clang][docs][release notes] mention asm goto support
Thanks to all people involved.
[1] https://github.com/llvm/llvm-project/commit/1634b4bc934d67cb5fa356a925ba8efca2259f12
dileks
on 27 Jul 2019
Related issues
nathanchance
·
4Comments
nickdesaulniers
·
5Comments
nickdesaulniers
·
4Comments
nickdesaulniers
·
3Comments
tpimh
·
3Comments
Most helpful comment
Prototype patch for LLVM: https://reviews.llvm.org/D53765 (IIRC, there should be a Clang patch, too. But there's little point posting it since the LLVM patches will probably undergo iteration before landing. Usually new features that require changes to LLVM land in LLVM first, then get a Clang patch added). Alexander has been driving the implementation, and I've been help test behind the scenes.