Bug 215819: clang 3.9.1 for TARGET_ARCH=powerpc64 generated R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc; 0(register) addressing results and crashes the kernel

[Mark Millard]

[As stands I've no clue if this is unique to FreeBSD's clang
somehow vs. if it is a general llvm powerpc64 problem. This
may need a llvm submittal as well.]

I have submitted FreeBSD bugzilla entry:

Bug 215819 - head r311147's clang 3.9.1 for powerpc64: locore.o generation messed up: generates R_PPC64_ADDR16_DS instead of R_PPC64_TOC16_DS with .toc 

Using objdump on locore.o I see variations based on clang vs. xtoolchain,
including the below relative to .toc handling:
(- -> clang , + -> xtoolchain)

RELOCATION RECORDS FOR [.text]:
OFFSET           TYPE              VALUE 
. . .
-0000000000000046 R_PPC64_ADDR16_DS  .toc
+0000000000000046 R_PPC64_TOC16_DS  .toc
. . .
-0000000000000182 R_PPC64_ADDR16_DS  .toc
+0000000000000182 R_PPC64_TOC16_DS  .toc
. . .
-0000000000000916 R_PPC64_ADDR16_DS  .toc
. . .
+0000000000000916 R_PPC64_TOC16_DS  .toc
. . .

(The above is based on objdump output differences.)

In the boot code (/boot/kernel/kernel) these match up with. . .

. . .
<.__start+0x44> ld      r1,0(r2)       # 100160+46 clang
vs.
<.__start+0x44> ld      r1,-32760(r2)  # 100120+46 xtoolchain

. . .
<rstcodeend+0x8> ld      r1,0(r2)      # 100160+182 clang
vs.
<rstcodeend+0x8> ld      r1,-32760(r2) # 100120+182 xtoolchain

. . .
<dbtrap+0x10> ld      r1,0(r1)         # 100160+916 clang
vs.
<dbtrap+0x10> ld      r1,-32760(r1)    # 100120+916 xtoolchain

(Based on more objdump output comparisons.)

clang's code does not boot; xtoolchain's code does.


In both cases devel/powerpc64-binutils was used instead of
bootstrapped binutils to produce the kernel.full file and
the like (because of the bootstrapped ld having its own
problems).

But if locore.o should have used R_PPC64_TOC16_DS for clang
3.9.1 then that is an earlier problem.


===
Mark Millard
markmi at dsl-only.net