Re: clang build kernel traps

On Wed, 22 Jan 2020 06:36:17 +0900
rgc <[email protected]> wrote:

> --- gcc4-obj/locore.s   Wed Jan 22 04:29:10 2020
> +++ clang-obj/locore.s  Wed Jan 22 04:29:05 2020
> ...

You might have found a problem with mftb (move from time base) in
clang's assembler.  Some of the other differences in your disassembly
might not cause problems.

This is a sample of the differences:

$ cat sample.s                                                         
	lwz	%r31,battable+4@l(%r31)
	mftb	%r28
	bla	s_dsitrap
	bc	4,17,s_trap
	addi	%r30,%r30,idledone@l
	nop
s_dsitrap:
	nop
cpu_switchto_asm:
	nop
idledone:
	nop
$ gcc -c sample.s
$ clang -c -o sample-clang.o sample.s
$ objdump -d sample.o > sample.ds
$ objdump -d sample-clang.o > sample-clang.ds
fishport$ diff -u sample.ds sample-clang.ds
...
 00000000 <s_dsitrap-0x18>:
-   0:	83 ff 00 04 	lwz     r31,4(r31)
-   4:	7f 8c 42 e6 	mftb    r28
-   8:	48 00 00 1b 	bla     18 <s_dsitrap>
+   0:	83 ff 00 00 	lwz     r31,0(r31)
+   4:	7f 8c 42 a6 	mfspr   r28,268
+   8:	48 00 00 03 	bla     0 <s_dsitrap-0x18>
    c:	40 91 00 10 	ble-    cr4,1c <s_trap>
-  10:	3b de 00 20 	addi    r30,r30,32
+  10:	3b de 00 00 	addi    r30,r30,0
   14:	60 00 00 00 	nop
...

The change from 4 to 0 in 'lwz r31,4(r31)' is not significant if the
relocation for 'battable+4@l' overwrites the 4 or 0 with a different
value.  I see that gcc and clang use the same relocations:

=begin
$ readelf -r sample.o sample-clang.o

File: sample.o

Relocation section '.rela.text' at offset 0x270 contains 3 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000002  00000704 R_PPC_ADDR16_LO   00000000   battable + 4
00000008  00000102 R_PPC_ADDR24      00000000   .text + 18
00000012  00000104 R_PPC_ADDR16_LO   00000000   .text + 20

File: sample-clang.o

Relocation section '.rela.text' at offset 0xc8 contains 3 entries:
 Offset     Info    Type            Sym.Value  Sym. Name + Addend
00000002  00000604 R_PPC_ADDR16_LO   00000000   battable + 4
00000008  00000502 R_PPC_ADDR24      00000000   .text + 18
00000012  00000504 R_PPC_ADDR16_LO   00000000   .text + 20
=end

Both gcc and clang use 'battable + 4' as the relocation for the
'battable+4@l' in the source code, so the 4 is not lost.  Each
relocation has a different symbol index (Info >> 8, see ELF32_R_SYM in
<sys/exec_elf.h>) because gcc and clang wrote the symbols in a
different order (readelf -s *.o), but the symbols 'battable' and
'.text' are the same.

Branches with predictions like bge- beq+ bne- might differ, because
newer versions of the Power ISA changed how to set the branch
prediction bits (but tried to be backward-compatible).

I recall that mftb (move from time base) is different between 32-bit
and 64-bit PowerPC, and suspect that clang might be using the wrong
mftb for our 32-bit target, but I won't know until I check the ISA
manual.

--George