[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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
