Re: clang build kernel traps
rgc <[email protected]> Wed, 22 Jan 2020 06:36:17 +0900
| Newsgroups | gmane.os.openbsd.ppc |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jan 22, 2020 at 12:42:53AM -0500, George Koehler wrote: > On Sun, 19 Jan 2020 11:32:26 +0900 > rgc <[email protected]> wrote: > > > ... > > > > On Sun, Jan 19, 2020 at 11:12:15AM +0900, rgc wrote: > > > ppc@ > > > > > > as title ... i've been playing around since i got 6.6-current installed. > > > > > > first build a gcc4 kernel and test if it boots properly. OK > > > > > > modified share/mk/bsd.own.mk; modified links to cc, c++, cpp; kernel > > > build without errors; these steps are from a 2018 mail on how to > > > "switch armv7 to clang" > > > > > > ... but does not boot > > > > > > ----- > > > [ using 1135748 bytes of bsd ELF symbol table ] > > > console out [ATY,Jasper_A] console in [keyboard], using USB > > > using parent ATY,JasperParent:[]-2147483648/0 sp=6db6db6d inside 80210194-38214000: not MAP_STACK > > > ----- > > > > > > ... > > clang still has bugs and can emit wrong assembly code. > and i think it is what i am seeing right now. for example /usr/src/sys/arch/macppc/macppc/locore.S:295 lwz %r30,_C_LABEL(battable)@l(%r31) /* get batu */ mtcr %r30 bc 4,30,1f /* branch if supervisor valid is false */ lwz %r31,_C_LABEL(battable)+4@l(%r31) /* get batl */ /* We randomly use the highest two bat registers here */ mftb %r28 andi. %r28,%r28,1 bne 2f mtdbatu 2,%r30 generates --- gcc4-obj/locore.s Wed Jan 22 04:29:10 2020 +++ clang-obj/locore.s Wed Jan 22 04:29:05 2020 @@ -197,9 +197,9 @@ 21a: R_PPC_ADDR16_LO battable 21c: 7f cf f1 20 mtcr r30 220: 40 9e 00 48 bne- cr7,268 <nopbat_1e> - 224: 83 ff 00 04 lwz r31,4(r31) + 224: 83 ff 00 00 lwz r31,0(r31) 226: R_PPC_ADDR16_LO battable+0x4 - 228: 7f 8c 42 e6 mftb r28 + 228: 7f 8c 42 a6 mfspr r28,268 22c: 73 9c 00 01 andi. r28,r28,1 230: 40 82 00 10 bne- 240 <nopbat_1s+0x3c> 234: 7f dc 83 a6 mtdbatu 2,r30 (full diff attached at the end) > MAP_STACK is documented in mmap(2). The kernel sometimes checks that > the cpu's stack pointer (register %r1 on PowerPC) points to MAP_STACK > memory. The check would fail if something corrupted the stack pointer; > "sp=6db6db6d" might be a corrupt value. You might get more info by > adding printf() calls and rebuilding the kernel. > > I reported https://bugs.llvm.org/show_bug.cgi?id=40736 where clang and > gcc use incompatible assembly code to return small structs, and am > working on a possible fix. Without a fix, user commands built by clang > might have trouble calling libraries built by gcc. If we fix enough > compatibility bugs, we might try building user commands with clang. > This might be easier than building the kernel. > > --George goodluck on you work. yorosiku ~ --- gcc4-obj/locore.s Wed Jan 22 04:29:10 2020 +++ clang-obj/locore.s Wed Jan 22 04:29:05 2020 @@ -197,9 +197,9 @@ 21a: R_PPC_ADDR16_LO battable 21c: 7f cf f1 20 mtcr r30 220: 40 9e 00 48 bne- cr7,268 <nopbat_1e> - 224: 83 ff 00 04 lwz r31,4(r31) + 224: 83 ff 00 00 lwz r31,0(r31) 226: R_PPC_ADDR16_LO battable+0x4 - 228: 7f 8c 42 e6 mftb r28 + 228: 7f 8c 42 a6 mfspr r28,268 22c: 73 9c 00 01 andi. r28,r28,1 230: 40 82 00 10 bne- 240 <nopbat_1s+0x3c> 234: 7f dc 83 a6 mtdbatu 2,r30 @@ -219,7 +219,7 @@ 00000268 <nopbat_1e>: nopbat_1e(): 268: 7f 88 02 a6 mflr r28 - 26c: 48 00 08 7f bla 87c <s_dsitrap> + 26c: 48 00 00 03 bla 0 <cpu_switchto_asm> 26c: R_PPC_ADDR24 .text+0x87c 00000270 <isitrap>: @@ -240,7 +240,7 @@ 28c: 7f a0 00 26 mfcr r29 290: 7f fb 02 a6 mfsrr1 r31 294: 7c 31 42 a6 mfsprg r1,1 - 298: 48 00 09 5b bla 958 <s_isitrap> + 298: 48 00 00 03 bla 0 <cpu_switchto_asm> 298: R_PPC_ADDR24 .text+0x958 0000029c <extint>: @@ -266,7 +266,7 @@ 2cc: 80 21 01 bc lwz r1,444(r1) 2d0: 41 82 00 08 beq- 2d8 <nop32_5e+0x2c> 2d4: 7c 31 42 a6 mfsprg r1,1 - 2d8: 48 00 09 ca ba 9c8 <extintr> + 2d8: 48 00 00 02 ba 0 <cpu_switchto_asm> 2d8: R_PPC_ADDR24 .text+0x9c8 000002dc <decrint>: @@ -418,9 +418,9 @@ 4dc: 38 42 ff f8 addi r2,r2,-8 4e0: 4b ff ff ac b 48c <tlbdsmiss+0x14> 4e4: 54 23 f0 03 rlwinm. r3,r1,30,0,1 - 4e8: 40 80 00 18 bge- 500 <tlbdsmiss+0x88> + 4e8: 40 c0 00 18 bge- 500 <tlbdsmiss+0x88> 4ec: 70 23 00 01 andi. r3,r1,1 - 4f0: 41 a2 00 28 beq+ 518 <tlbdsmiss+0xa0> + 4f0: 41 e2 00 28 beq+ 518 <tlbdsmiss+0xa0> 4f4: 7c 7b 02 a6 mfsrr1 r3 4f8: 3c 20 0a 00 lis r1,2560 4fc: 48 00 00 34 b 530 <tlbdsmiss+0xb8> @@ -429,7 +429,7 @@ 508: 7c 7b 02 a6 mfsrr1 r3 50c: 54 63 97 fe rlwinm r3,r3,18,31,31 510: 5c 21 18 43 rlwnm. r1,r1,r3,1,1 - 514: 40 a2 ff e0 bne- 4f4 <tlbdsmiss+0x7c> + 514: 40 c2 ff e0 bne+ 4f4 <tlbdsmiss+0x7c> 518: 80 22 00 04 lwz r1,4(r2) 51c: 60 21 01 80 ori r1,r1,384 520: b0 22 00 06 sth r1,6(r2) @@ -468,7 +468,7 @@ 580: 7f d0 42 a6 mfsprg r30,0 584: 83 de 01 bc lwz r30,444(r30) 588: 38 3e 20 00 addi r1,r30,8192 - 58c: 48 00 0d 83 bla d80 <ddbtrap> + 58c: 48 00 00 03 bla 0 <cpu_switchto_asm> 58c: R_PPC_ADDR24 .text+0xd80 00000590 <disitrap>: @@ -487,8 +487,7 @@ 5b0: 7c 3b 02 a6 mfsrr1 r1 5b4: 7c 2f f1 20 mtcr r1 5b8: 7c 31 42 a6 mfsprg r1,1 - 5bc: 40 91 00 00 ble- cr4,5bc <realtrap+0xc> - 5bc: R_PPC_REL14 s_trap + 5bc: 40 91 00 10 ble- cr4,5cc <s_trap> 5c0: 7c 30 42 a6 mfsprg r1,0 5c4: 80 21 01 94 lwz r1,404(r1) 5c8: 38 21 40 00 addi r1,r1,16384 @@ -566,7 +565,7 @@ 6d4: 90 c5 01 b4 stw r6,436(r5) 6d8: 3f c0 00 00 lis r30,0 6da: R_PPC_ADDR16_HA .text+0x128 - 6dc: 3b de 01 28 addi r30,r30,296 + 6dc: 3b de 00 00 addi r30,r30,0 6de: R_PPC_ADDR16_LO .text+0x128 6e0: 93 c1 00 98 stw r30,152(r1) 6e4: 93 e1 00 9c stw r31,156(r1) @@ -684,8 +683,7 @@ 86c: 7f e8 03 a6 mtlr r31 870: 7f c3 f3 78 mr r3,r30 874: 4e 80 00 21 blrl - 878: 48 00 00 00 b 878 <fork_trampoline+0x14> - 878: R_PPC_REL24 trapexit + 878: 4b ff fe 94 b 70c <trapexit> 0000087c <s_dsitrap>: s_dsitrap(): @@ -854,7 +852,6 @@ 00000ac4 <extint_call>: extint_call(): ac4: 48 00 00 01 bl ac4 <extint_call> - ac4: R_PPC_REL24 extint_call 00000ac8 <intr_exit>: intr_exit(): @@ -1121,7 +1118,7 @@ e88: 90 c5 01 b4 stw r6,436(r5) e8c: 3f c0 00 00 lis r30,0 e8e: R_PPC_ADDR16_HA .text+0x128 - e90: 3b de 01 28 addi r30,r30,296 + e90: 3b de 00 00 addi r30,r30,0 e92: R_PPC_ADDR16_LO .text+0x128 e94: 93 c1 00 98 stw r30,152(r1) e98: 93 e1 00 9c stw r31,156(r1) @@ -1302,61 +1299,34 @@ 1114: 60 00 00 00 nop 00001118 <rfi_start>: -rfi_start(): - 1118: 00 00 08 60 .long 0x860 + ... 1118: R_PPC_ADDR32 .text+0x860 - 111c: 00 00 08 64 .long 0x864 111c: R_PPC_ADDR32 .text+0x864 - 1120: 00 00 09 54 .long 0x954 1120: R_PPC_ADDR32 .text+0x954 - 1124: 00 00 09 58 .long 0x958 1124: R_PPC_ADDR32 .text+0x958 - 1128: 00 00 0c 18 .long 0xc18 1128: R_PPC_ADDR32 .text+0xc18 - 112c: 00 00 0c 1c .long 0xc1c 112c: R_PPC_ADDR32 .text+0xc1c - 1130: 00 00 11 08 .long 0x1108 1130: R_PPC_ADDR32 .text+0x1108 - 1134: 00 00 11 0c .long 0x110c 1134: R_PPC_ADDR32 .text+0x110c - ... 00001140 <nopbat_start>: -nopbat_start(): - 1140: 00 00 02 04 .long 0x204 + ... 1140: R_PPC_ADDR32 .text+0x204 - 1144: 00 00 02 68 .long 0x268 1144: R_PPC_ADDR32 .text+0x268 - ... 00001150 <nop32_start>: -nop32_start(): - 1150: 00 00 01 50 .long 0x150 + ... 1150: R_PPC_ADDR32 .text+0x150 - 1154: 00 00 01 5c .long 0x15c 1154: R_PPC_ADDR32 .text+0x15c - 1158: 00 00 01 90 .long 0x190 1158: R_PPC_ADDR32 .text+0x190 - 115c: 00 00 01 9c .long 0x19c 115c: R_PPC_ADDR32 .text+0x19c - 1160: 00 00 01 e4 .long 0x1e4 1160: R_PPC_ADDR32 .text+0x1e4 - 1164: 00 00 01 f0 .long 0x1f0 1164: R_PPC_ADDR32 .text+0x1f0 - 1168: 00 00 02 74 .long 0x274 1168: R_PPC_ADDR32 .text+0x274 - 116c: 00 00 02 80 .long 0x280 116c: R_PPC_ADDR32 .text+0x280 - 1170: 00 00 02 a0 .long 0x2a0 1170: R_PPC_ADDR32 .text+0x2a0 - 1174: 00 00 02 ac .long 0x2ac 1174: R_PPC_ADDR32 .text+0x2ac - 1178: 00 00 02 e0 .long 0x2e0 1178: R_PPC_ADDR32 .text+0x2e0 - 117c: 00 00 02 ec .long 0x2ec 117c: R_PPC_ADDR32 .text+0x2ec - 1180: 00 00 05 64 .long 0x564 1180: R_PPC_ADDR32 .text+0x564 - 1184: 00 00 05 70 .long 0x570 1184: R_PPC_ADDR32 .text+0x570 - ...