Bug 1267395 - new binutils 2.25.1-1 exposing incorrect tlbie operand on powerpc
new binutils 2.25.1-1 exposing incorrect tlbie operand on powerpc
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F-ExcludeArch-ppc64le/PPC64LETracker 1300586
  Show dependency treegraph
 
Reported: 2015-09-29 18:34 EDT by Laura Abbott
Modified: 2017-02-14 09:31 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1300586 (view as bug list)
Environment:
Last Closed: 2015-10-12 13:04:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
error log with full commands (8.56 KB, text/plain)
2015-09-30 12:57 EDT, Laura Abbott
no flags Details
preproccesed file (7.17 KB, text/plain)
2015-09-30 12:59 EDT, Laura Abbott
no flags Details
cross gcc from local machine (765.60 KB, application/x-executable)
2015-10-01 13:38 EDT, Laura Abbott
no flags Details
cross as from local machine (1.50 MB, application/x-executable)
2015-10-01 13:38 EDT, Laura Abbott
no flags Details

  None (edit)
Description Laura Abbott 2015-09-29 18:34:03 EDT
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.
Comment 1 Nick Clifton 2015-09-30 09:28:14 EDT
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
Comment 2 Laura Abbott 2015-09-30 12:57 EDT
Created attachment 1078745 [details]
error log with full commands

make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- &> errlog.txt
Comment 3 Laura Abbott 2015-09-30 12:59 EDT
Created attachment 1078748 [details]
preproccesed file

make V=1 ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- arch/powerpc/kernel/swsusp_asm64.s
Comment 4 Laura Abbott 2015-09-30 13:10:28 EDT
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
Comment 5 Nick Clifton 2015-10-01 09:41:34 EDT
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
Comment 6 Laura Abbott 2015-10-01 13:35:30 EDT
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.
Comment 7 Laura Abbott 2015-10-01 13:38 EDT
Created attachment 1079213 [details]
cross gcc from local machine
Comment 8 Laura Abbott 2015-10-01 13:38 EDT
Created attachment 1079214 [details]
cross as from local machine
Comment 10 Nick Clifton 2015-10-02 09:59:17 EDT
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
Comment 11 Laura Abbott 2015-10-02 11:45:48 EDT
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.
Comment 12 Laura Abbott 2015-10-05 15:46:41 EDT
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
Comment 13 Laura Abbott 2015-10-07 11:22:54 EDT
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.
Comment 14 Laura Abbott 2015-10-12 13:04:53 EDT
I pushed a fix to disable hibernation. I'm marking this as closed. This bug can be re-evaluated if someone wants hibernation.

Note You need to log in before you can comment on or make changes to this bug.