Created attachment 167575 [details] Patches to build for ppc64 with clang Used the attached modifications to build ppc64 kernel with clang (building world only required a small kludge with bfd ld but otherwise works fine). Same kernel was tested building with CC:= gcc and COMPILER_TYPE:= gcc in sys/conf/Makefile.powerpc64 and that kernel boot just fine. I would like to get the kernel built by clang work though... make.conf used: NO_WERROR = WERROR = WITH_CLANG = yes WITH_CLANG_BOOTSTRAP = yes WITH_CLANG_FULL = yes WITH_CLANG_IS_CC = yes WITH_GCC = yes WITH_GCC_BOOTSTRAP = yes WITHOUT_GNUCXX = yes When booting, hangs here: Kernel entry at 0x100160 ... objdump says that 0x100160 is a good address in /boot/kernel/kernel pointing to __start like it should: 0000000000100160 <.__start>: 100160: 48 00 00 08 b 100168 <.__start+0x8> 100164: 60 00 00 00 nop 100168: 60 00 00 00 nop 10016c: 48 00 00 0d bl 100178 <.__start+0x18> 100170: 00 00 00 00 .long 0x0 100174: 00 4b be 90 .long 0x4bbe90 100178: 7c 48 02 a6 mflr r2 10017c: e8 22 00 00 ld r1,0(r2) 100180: 7c 41 12 14 add r2,r1,r2 100184: eb e2 80 00 ld r31,-32768(r2) 100188: 7f ff 10 50 subf r31,r31,r2 10018c: e8 22 00 00 ld r1,0(r2) 100190: 38 21 3f a0 addi r1,r1,16288 100194: 7c 21 fa 14 add r1,r1,r31 100198: f8 61 00 30 std r3,48(r1) 10019c: f8 81 00 38 std r4,56(r1) 1001a0: f8 a1 00 40 std r5,64(r1) Contents of CPU registers: (qemu) info registers NIP 000000007dbe0780 LR 000000007dbe0308 CTR 000000007dbe0210 XER 000000000000 MSR 0000000000000010 HID0 0000000000000000 HF 0000000000000000 idx 1 TB 00000003 16089762103 DECR 1090107081 GPR00 000000007dbe0780 000000007e45e0f0 000000007dbff728 0000000000000003 GPR04 0000000000000380 0000000000003950 000000007dc3f728 0000000000000fe0 GPR08 0000000000000080 000000000073ed10 0000000000000000 0000000000000000 GPR12 0000000000743900 0000000000708f50 0000000000000000 0000000000000000 GPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20 0000000000000000 0000000001801bc0 00000000005bc000 0000000000009001 GPR24 00000000005bc000 0000000000743900 0000000000708f50 000000000073ee20 GPR28 0000000000002000 ffffffffffffffff 0000000000003d98 0000000000003a20 CR 84400028 [ L G G - - - E L ] RES ffffffffffffffff FPR00 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR04 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR08 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR12 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR16 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR20 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR24 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPR28 0000000000000000 0000000000000000 0000000000000000 0000000000000000 FPSCR 0000000000000000 SRR0 000000007dbe0780 SRR1 0000000000000010 PVR 00000000004d0100 VRSAVE 000 SPRG0 000000007dbe0308 SPRG1 000000007e45e0f0 SPRG2 000000007dbe0210 SPRG3 008 SPRG4 0000000000000000 SPRG5 0000000000000000 SPRG6 0000000000000000 SPRG7 000 CFAR 000000007dbe033c SDR1 0000000043230007 DAR 000000007dc41000 DSISR 0000000000000000 Any help on where to begin troubleshooting where the execution is stopping would be appreciated. Which source file for the kernel contains the first set of instructions when control is handed over from the boot loader? Thanks.
(In reply to Kenneth Salerno from comment #0) FYI: https://llvm.org/bugs/show_bug.cgi?id=25780 has a list of reports that FreeBSD requires to be fixed in order for clang to be the system compiler for powerpc and/or powerpc64. Some of the points are powerpc-only issues but some of the material also applies to powerpc64. (powerpc64 has had less checking/testing.) One of the major things messed up is C++ exception handling, with several issues contributing to the overall status. That in turn messes up being able to use kyua for testing: kyua uses C++ exception handling extensively. The kernel's own code may systematically avoid using some of the messed up code generation: most of the reported material that was based on testing is for buildworld attempts for TARGET_ARCH=powerpc. Some of the powerpc64 material was just noted by someone to be analogous in the clang source code. Some of the code generation problems are reported to be low probability outside the C++ exception handling context that forces certain examples of some more general issues. If you find more clang powerpc64 code generation problems it would be good to add more reports on llvm.org/bugs and have them listed in llvm.org/bug's 25780. It may be that some of the material in the comments for some of the llvm.org/bugs submittals might eventually need their own submittals if the fixing-effort is sufficiently distinct. As stands some of the one-line descriptions only indicate an example of multiple related issues reported in the comments.
(In reply to Mark Millard from comment #1) Thanks, Mark. I looked through the LLVM ticket and didn't find anything relevant to this issue on powerpc64 clang. Seems to be hanging at branch to counter register (when I compared to the asm generated by GCC, that code had instead a branch to link register). I even tried building the kernel modules with GCC where -mlongcall was needed and clang for everything else, though soft-float is a missing option in clang that I'm not sure is necessary or not. I noticed building with altivec support kills the kernel load even sooner so maybe soft-float is a necessary switch clang needs for powerpc64 to build a working kernel?
Created attachment 169265 [details] Latest patchset to build ppc64 world+kernel with clang Attaching latest patchset against 11-CURRENT r297632
Created attachment 169266 [details] Patch set to build ppc64 world+kernel with clang Cleaned up the patches to not step on other arches.
Is this patch still relevant? clang has had -msoft-float for a while now, and most of the rest has already been taken care of via patches committed for other bugs.
(In reply to Justin Hibbits from comment #5) Hi, you can close this. I have been building for ppc64 with gcc6.
(In reply to Kenneth Salerno from comment #6) Just for reference because it could be easy to miss: Comment 6 is reporting switching from clang to gcc6 for builds. It does not report that the clang context now works or anything about the status of the patch relative to clang.