New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x86{,_64} build hangs after next-20181008 #213
Comments
Does |
I don't think so, here's the last bit I see
|
so |
I've gone ahead and compiled with Here is a screenshot of |
Looks like removing diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 73f4831283ac..4d3612ad0f77 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -239,7 +239,7 @@ archheaders:
archmacros:
$(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s
-ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s -Wa,-
+ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s
export ASM_MACRO_FLAGS
KBUILD_CFLAGS += $(ASM_MACRO_FLAGS)
|
From your screenshot, you can see that I have no idea what |
Yeah I think you are right, I'll be able to confirm later. Unfortunately, GCC completely blows up with that diff but it's entirely possible that flag just needs to be added if Clang isn't being used. I'll see if I can get qemu set up to boot a kernel compiled with Clang + that diff and see if anything explodes. |
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 73f4831283ac..be8be3dd38b1 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -239,7 +239,10 @@ archheaders:
archmacros:
$(Q)$(MAKE) $(build)=arch/x86/kernel arch/x86/kernel/macros.s
-ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s -Wa,-
+ASM_MACRO_FLAGS := -Wa,arch/x86/kernel/macros.s
+ifneq ($(cc-name),clang)
+ASM_MACRO_FLAGS += -Wa,-
+endif
export ASM_MACRO_FLAGS
KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) I can build and boot this diff into a Debian shell in QEMU with both GCC 8.2.1 and Clang 8 ( |
I too could repro locally. That change looks good, but I kind of want to ask the author what that's doing, since I don't understand it. |
Yeah I think I'll send it as an RFC now just to see what they say. My guess is it has something to do with how Clang and GCC fork off gas. |
Filed a bug to investigate this on the Clang side: https://llvm.org/pr39410 |
Isn't it expected that passing |
Commit 77b0bf5 ("kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs") added -Wa,- to KBUILD_CFLAGS, which breaks compiling with Clang (hangs indefinitely at compiling init/main.o). This happens because while Clang accepts -pipe (and has it documented in its list of supported flags), it silently ignores it after this 2010 commit (thanks to Nick Desaulniers for tracking this down), meaning that gas just infinitely waits for stdin and never receives it. llvm-mirror/clang@c19a12d Initially, I had suggested just add -Wa,- to KBUILD_CFLAGS when GCC was being used but that was before realizing it is because Clang doesn't do anything with -pipe. H. Peter Anvin suggested checking to see if -pipe gives us any gains out of GCC. Turns out it might actually be hurting: With -pipe: real 3m40.813s real 3m44.449s real 3m39.648s Without -pipe: real 3m38.492s real 3m38.335s real 3m38.975s The issue of -Wa,- being passed along to gas without -pipe being supported should still probably be fixed on the LLVM side (open issue: https://bugs.llvm.org/show_bug.cgi?id=39410) but this is not as much of a workaround anymore since it helps both GCC and Clang. Link: ClangBuiltLinux#213 Suggested-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Merged and released in 4.20-rc2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=437e88ab8f9e2ad90576ab74c4cf8f527bbf51cd |
Can be reproduced with
defconfig
with or withoutCONFIG_64BIT
set:It seems to be stuck at
init/version.o
, as I see this when I interrupt the build:Bisect log:
Bad commit: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=77b0bf55bc675233d22cd5df97605d516d64525e
I applied @bulwahn's three patches in #186 to make sure none of my own patches were causing any issues.
The text was updated successfully, but these errors were encountered: