Hide Forgot
Compiling vanilla upstream kernel on ppc64le currently fails with binutils 2.25.1-1. The problem is observed on rawhide as well as F22 with the newer package. Both native and cross binutils are affected http://ppc.koji.fedoraproject.org/koji/getfile?taskID=2772584&name=build.log&offset=-4000 [labbott@labbott-redhat-machine linux_upstream]$ make ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK include/generated/bounds.h CHK include/generated/timeconst.h CHK include/generated/asm-offsets.h CALL scripts/checksyscalls.sh CHK include/generated/compile.h CALL arch/powerpc/kernel/systbl_chk.sh AS arch/powerpc/kernel/swsusp_asm64.o arch/powerpc/kernel/swsusp_asm64.S: Assembler messages: arch/powerpc/kernel/swsusp_asm64.S:188: Error: missing operand scripts/Makefile.build:294: recipe for target 'arch/powerpc/kernel/swsusp_asm64.o' failed make[1]: *** [arch/powerpc/kernel/swsusp_asm64.o] Error 1 Makefile:941: recipe for target 'arch/powerpc/kernel' failed make: *** [arch/powerpc/kernel] Error 2 [labbott@labbott-redhat-machine linux_upstream]$ powerpc64-linux-gnu-as --version GNU assembler version 2.25.1-1.fc22 Copyright (C) 2014 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `powerpc64-linux-gnu'. [labbott@labbott-redhat-machine linux_upstream]$ The associated line in the kernel is only a tlbia instruction which doesn't seem to need any arguments.
Hi Laura, Would it be possible capture the exact assembler command line that it being used ? I am trying to reproduce the problem locally, but so far I have had no luck. Also if you could upload the preprocessed version of the swsup_asm64.S source file that would help a great deal too. Cheers Nick
Created attachment 1078745 [details] error log with full commands make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- &> errlog.txt
Created attachment 1078748 [details] preproccesed file make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- arch/powerpc/kernel/swsusp_asm64.s
For reference, I think this is what the tlbia expands into li %r4,1024; mtctr %r4; lis %r4,0xc000000000000000@h; 0: tlbie %r4; addi %r4,%r4,0x1000; bdnz 0b
Hi Laura, Thanks for those files. Unfortunately I still cannot reproduce the problem. I have tried using the binutils and cross-binutils packages, using the F22, F23 and rawhide versions, and they all work. :-( My best guess now is that it is connected to the cross-gcc that you are using (powerpc64-linux-gnu-gcc). This invokes the assembler on the preprocessed file, and maybe, just maybe, it is using the wrong set of command line options to do so. I did try running the gcc command locally, using my own version of powerpc64-linux-gnu-gcc built from the mainline gcc sources, but this failed. (As in, it worked, it executed the assembler and the assembler created the object file without any warnings). Either that, or the cross-binutils that you are using has been configured with a different set of patches to the one that I am using. Would it be possible for you to point me at the powerpc64-linux-gnu-as executable that you are using (or upload it here), so that I can try running it myself ? Cheers Nick
The original issue was reproducible without cross compilation. the log file I linked from the koji build was compiling on powerpc64le natively http://ppc.koji.fedoraproject.org/koji/getfile?taskID=2772584&name=build.log&offset=-4000 and http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2772584 . I'll give you the files from my local machine and see if I can get the files from the build machine as well.
Created attachment 1079213 [details] cross gcc from local machine
Created attachment 1079214 [details] cross as from local machine
pbrobinson pointed out you can grab see what was installed from the log http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=2772584, http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/2584/2772584/root.log http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=343648 http://ppc.koji.fedoraproject.org/koji/buildinfo?buildID=326293
Hi Laura, Thanks very much for those executables. With them I was able to reproduce the problem, and find out why I could not reproduce it before. The powerpc64-linux-gnu-gcc that you are using is set up to produce Power7 binaries by default. The version that I was using was not. This also explains the problem. The TLBIE instruction needs *two* operands if it is being assembled for the Power7 architecture. Hence the assembler is correct in issuing its error message. It looks to me as if the translation from the TLBIA pseudo-instruction to the assembler sequence containing the TLBIE instruction is broken. (Or rather, the sequence works for most PPC architectures, just not the Power7). Do you know where this translation from TLBIA to TLBIE happens ? In a header file perhaps ? Wherever it is, I think that it needs to be fixed. The reason that this problem has only come to light now is that code to check the number of operands to the TLBIE instruction (for Power7) was only recently added: https://sourceware.org/ml/binutils/2015-05/msg00133.html Cheers Nick
Thanks for the analysis, you are spot on. I found the offending sequence in one of the header files: #if !defined(CONFIG_4xx) && !defined(CONFIG_8xx) #define tlbia \ li r4,1024; \ mtctr r4; \ lis r4,KERNELBASE@h; \ 0: tlbie r4; \ addi r4,r4,0x1000; \ bdnz 0b #endif which does indeed need to be updated. I sent a message to the powerpc maintainers upstream. Hopefully they will get back to me soon.
As an update, there is an ongoing thread but apparently someone wants to re-factor the code. No response on anyone doing the refactoring https://lkml.org/lkml/2015/10/2/494
The discussion upstream hasn't come to any conclusion yet. Given this is preventing compilation on rawhide, I'm going to push a patch to disable hibernation in rawhide after discussions with Josh.
I pushed a fix to disable hibernation. I'm marking this as closed. This bug can be re-evaluated if someone wants hibernation.