Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Roman Divacky
That's a great progress. Can you produce minimal self contained test case that exhibits this bug? And submit it to llvm bugzilla? Also, clang3.9 defaults to using it's own internal asm, what happens if you add -no-integrated-as to CFLAGS and recompile the kernel? That should remove this llvm assem

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Mark Millard
On 2017-Jan-7, at 12:51 AM, Roman Divacky wrote: > That's a great progress. Can you produce minimal self contained test case that > exhibits this bug? And submit it to llvm bugzilla? > > Also, clang3.9 defaults to using it's own internal asm, what happens if you > add -no-integrated-as to CFLAGS

[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

2017-01-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819 --- Comment #3 from Mark Millard --- (In reply to Mark Millard from comment #0) I found how to control the behavior based on the assembler notation @toc being missing vs. being present. If llvm should change is strongly tied to llvm's cri

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Mark Millard
[I've supplied a list of places that adding @toc notation should make clang 3.9.1 targeting powerpc64 do the right thing for this issue.] On 2017-Jan-7, at 2:07 PM, Mark Millard wrote: > On 2017-Jan-7, at 12:51 AM, Roman Divacky wrote: > >> That's a great progress. Can you produce minimal self

[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

2017-01-07 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215819 --- Comment #4 from Mark Millard --- (In reply to Mark Millard from comment #2) The following locore64_simplified.S source code is sufficient to show the silent R_PPC64_ADDR16_DS generation problem: .align 4 .data

Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . [Actually .__start code failure vs. working and R_PPC64_ADDR16_DS vs. R_PPC64_TOC16_DS]

2017-01-07 Thread Mark Millard
[Top post about FreeBSD bugzilla 215819 and llvm bugzilla 31574 submittals for the issue involved.] My guess is that FreeBSD will view this as a kernel source code issue and not as a toolchain issue. But it is only a guess on my part. I have submitted llvm bugzilla 31574 for this issue. It inclu

clang 3.9.1 based TARGET_ARCH=powerpc64 buildworld buildkernel for head -r311147 variant booted on PowerMac G5; used modern (2.27) devel/powerpc-binutils

2017-01-07 Thread Mark Millard
This was an amd64 -> powerpc64 cross build (kernel-toolchain buildkernel and separately buildworld). [Note: Anything dependent on throwing C++ exceptions in code generated by clang++ 3.9.1 is broken.] Various details: Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1