Re: toolchain/48675: evbarm userland fails to build in current with sources checked out March 21, 2014

["David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>]

The following reply was made to PR toolchain/48675; it has been noted by GNATS.

From: "David H. Gutteridge" <dhgutteridge%sympatico.ca@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: toolchain/48675: evbarm userland fails to build in current with 
sources checked out March 21, 2014
Date: Tue, 8 Apr 2014 22:26:48 -0400

 At first I wondered if this was simple user error on my part (and it
 may well still be), so I tried rebuilding again after making sure I
 had indeed started a build with what should be a clean tree. (I ran
 ./build.sh cleandir and then in the subsequent build didn't pass the
 -u flag to the script, for redundancy.) That time the build failed
 again, but in a different place:
 
 #   compile  libgmp/diveby3.o
 =
 /usr/builds/netbsd-current/src/obj/tooldir.NetBSD-5.2_STABLE-i386/bin/arm-=
 -netbsdelf-gcc   -pipe -O2 -fPIC -msoft-float -Wno-stack-protector -marm =
  -c    diveby3.s -o diveby3.o
 diveby3.s: Assembler messages:
 diveby3.s:76: Error: unrecognized symbol type ""
 diveby3.s:78: Error: bad instruction `lwz 11,0(4)'
 diveby3.s:79: Error: bad instruction `mtctr 5'
 diveby3.s:80: Error: bad instruction `lis 12,0xAAAA'
 diveby3.s:81: Error: bad instruction `ori 12,12,0xAAAB'
 diveby3.s:82: Error: bad instruction `li 10,3'
 diveby3.s:84: Error: bad instruction `cmplw 7,6,11'
 diveby3.s:85: Error: bad instruction `subf 11,6,11'
 diveby3.s:87: Error: bad instruction `mullw 0,11,12'
 diveby3.s:88: Error: bad instruction `stw 0,0(3)'
 diveby3.s:89: Error: bad instruction `bdz .Lone'
 diveby3.s:91: Error: bad instruction `lwzu 9,4(4)'
 diveby3.s:92: Error: bad instruction `mulhwu 7,0,10'
 diveby3.s:93: Error: bad instruction `bgt- 7,.Ladj'
 diveby3.s:94: Error: bad instruction `cmplw 7,7,9'
 diveby3.s:95: Error: bad instruction `subf 0,7,9'
 diveby3.s:96: Error: bad instruction `mullw 0,12,0'
 diveby3.s:97: Error: bad instruction `stwu 0,4(3)'
 diveby3.s:98: Error: bad instruction `bdnz .Ltop'
 diveby3.s:100: Error: bad instruction `mulhwu 3,0,10'
 diveby3.s:101: Error: bad instruction `blelr+ 7'
 diveby3.s:102: Error: bad instruction `addi 3,3,1'
 diveby3.s:103: Error: bad instruction `blr'
 diveby3.s:105: Error: bad instruction `addi 7,7,1'
 
 *** Failed target:  diveby3.o
 *** Failed command: =
 /usr/builds/netbsd-current/src/obj/tooldir.NetBSD-5.2_STABLE-i386/bin/arm-=
 -netbsdelf-gcc -pipe -O2 -fPIC -msoft-float -Wno-stack-protector -marm =
 -c diveby3.s -o diveby3.o
 *** Error code 1
 
 The diveby3.s file has 72 lines of blank spaces followed by some
 PowerPC assembly code:
 
         .section        ".text"
         .align  3
         .globl  __gmpn_divexact_by3c
         .type   __gmpn_divexact_by3c, @function
 __gmpn_divexact_by3c:
         lwz     11, 0(4)
         mtctr   5
         lis     12, 0xAAAA
         ori     12, 12, 0xAAAB
         li      10, 3
 
         cmplw   7, 6, 11
         subf    11, 6, 11
 
         mullw   0, 11, 12
         stw     0, 0(3)
         bdz     .Lone
 
 .Ltop:  lwzu    9, 4(4)
         mulhwu  7, 0, 10
         bgt-    7, .Ladj               =20
 .Lbko:  cmplw   7, 7, 9
         subf    0, 7, 9
         mullw   0, 12, 0
         stwu    0, 4(3)
         bdnz    .Ltop
 
 .Lone:  mulhwu  3, 0, 10
         blelr+  7
         addi    3, 3, 1
         blr
 
 .Ladj:  addi    7, 7, 1
         b       .Lbko
         .size   __gmpn_divexact_by3c, .-__gmpn_divexact_by3c
 
 Some time ago, I was using this tree to build test kernels for macppc,
 so this is presumably a leftover from that time, but I don't follow
 why files like this wouldn't be cleaned out. After running "build.sh
 cleandir" again at the top of the tree, I found that the directory in
 question definitely wasn't being cleaned out. It's:
 /home/disciple/netbsd-current/src/external/lgpl3/gmp/lib/libgmp/obj
 
 I also checked the mpc and mpfr trees to see if they had the same
 issue, but they don't, only gmp does.
 
 Is it expected that users would have to clean out particular assembly
 or object files manually? Am I doing something fundamentally wrong?