Mark, Would you be interested in trying lld? It has some support for ppc/ppc64, which is probably quite incomplete but it would be nice to know what exactly is missing.
We also have some people (emaste@, davide@) that have non-trivial lld knowledge so perhaps progress can be achieved on this side easily? Roman On Sun, Jan 08, 2017 at 02:57:11AM -0800, Mark Millard wrote: > [I forgot to indicate that I still can not use the system bootstrapped > ld command and so there is a reason that I used devel/powerpc64-binutils.] > > On 2017-Jan-8, at 2:24 AM, Mark Millard <markmi at dsl-only.net> wrote: > > > On 2017-Jan-8, at 1:03 AM, Roman Divacky <rdivacky at vlakno.cz> wrote: > > > >> I think we should add the @toc notations to all the places where it's > >> needed. > >> Can you submit such a patch (perhaps with the one for adding 0 to the cmp > >> instruction) so they can be committed to FreeBSD repo? > > > > In order to test I added @toc to each of the 10 instructions instead > > of adjusting the macros so that instructions would automatically > > get the notation but other (what are now) TOC_REF(...) usage would > > not that should not. > > > > I suspect Nathan and Justin might prefer a more automatic > > alternative so that TOC_REF(...) in an instruction would > > be sufficient without an explicit @toc in the instruction. > > > > I'll see about switching to such code before providing a > > patch. I'd include the "0, " update to the cmp instruction. > > > > But adding @toc's in those instructions (with prior workarounds > > as well) did allow me to build a bootable system based on using > > devel/powerpc64-binutils and clang 3.9.1 for both buildworld > > and buildkernel --still using clang's internal assembler. > > > > One issue is that clang does not support (or need) the > > -mminmal-toc in sys/modules/zfs/Makefile but gcc 4.2.1 > > requires it. For sys/modules/zfs/Makefile my source > > currently does not support gcc 4.2.1 without editing. > > As I remember devel/powerpc64-gcc > > (devel/powerpc64-xtoolchain-gcc) does not require the > > -mminimal-toc either. But devel/powerpc64-gcc does > > allow -mminimal-toc so it can be a clang vs. gcc based > > choice. > > > > I might also deal with that before providing patches. > > > > Note: -mlongcall was also not needed nor used for clang. > > (Still used for gcc.) > > > > sys/boot/powerpc/kboot/Makefile has a -mcpu=powerpc64 > > and -Wa,-mppc64bridge that I eliminated (they messed up > > 32-bit powerpc builds) but I've no way to test kboot that > > I know of. This patch might be rejected. > > > > Remember that I got this far in part by using your partial > > e500-instructions patch. I can provide my variant that > > is a diff with -r311147 instead of an older place in the > > history. But it would be incomplete coverage of those 2 > > instructions in clang. > > > > Also I build with a workaround for PowerMac G5 boot > > reliability since OpenFirmware and FreeBSD interact > > badly at times on PowerMac G5's. This I would not > > provide as it is PowerMac G5 specific. > > > >> If gnu as warns and llvm assembler does the wrong thing without @toc and > >> both > >> do the correct thing with @toc I think it's an obvious decision. > > > > My choice would be to supply the @toc notation in some way, > > not necessarily the form I used for the initial test. > > > >> Also, with all these changes. Does clang compiled kernel boot? > > > > The PowerMac G5 so-called "Quad Core" that I currently have access > > to is now running from buildworld and buildkernel based on > > devel/powerpc64-binutils and clang 3.9.1 : > > > > Copyright (c) 1992-2017 The FreeBSD Project. > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > The Regents of the University of California. All rights reserved. > > FreeBSD is a registered trademark of The FreeBSD Foundation. > > FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 16:55:01 PST 2017 > > > > markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG > > powerpc > > FreeBSD clang version 3.9.1 (tags/RELEASE_391/final 289601) (based on LLVM > > 3.9.1) > > . . . > > > > # uname -apKU > > FreeBSD FBSDG5L 12.0-CURRENT FreeBSD 12.0-CURRENT #2 r311147M: Sat Jan 7 > > 16:55:01 PST 2017 > > markmi@FreeBSDx64:/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG > > powerpc powerpc64 1200019 1200019 > > > > I've built about a dozen ports on it after booting but I've not > > done a self-hosted buildworld buildkernel yet. > > > > [Note: Anything dependent on throwing C++ exceptions in > > code generated by clang++ 3.9.1 is broken.] > > I should have been explicit: > > I still can not use the system bootstrapped ld command > and such binutils for buildkernel and so there is a > reason that I used devel/powerpc64-binutils instead. > > Thus even with my patches clang 3.9.1 would not be ready > for general use or for a default way of building. I > have to have a tailored SRC_ENV_CONF file or the like > still --and a port built and installed. > > [On a powerpc64 system devel/binutils could be used.] > > There is also the issue with throwing C++ exceptions > in code when clang 3.9.1 was the code generator used. > > === > Mark Millard > markmi at dsl-only.net > > On Sat, Jan 07, 2017 at 04:28:48PM -0800, Mark Millard wrote: > > [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 > > includes example .S file content that shows the "problem" > > in the generated .o file (form FreeBSD's view point). > > (I've no clue how llvm views its criteria relative to this > > mismatch with gcc/binutils.) > > > > Because FreeBSD source code changes (being explicit about > > @toc) avoid the distinction between clang and gcc/binutils > > I've not added 31574 to the Depends on list for llvm 25780 > > (the FreeBSD system compiler issues META entry in llvm). > > > > Someone with official status for FreeBSD could add 31574 to > > llvm's 25780 if FreeBSD wants to push llvm to match > > gcc/binutils for "@toc notation missing". > > > > Otherwise this is a kernel source code issue (as I would > > guess) and not a toolchain issue. > > > > Ed Maste or someone like that likely would make the final > > decision. > > > > > > I've added to FreeBSD Bugzilla 215819 the new information, > > including the simple example .S file content that shows the > > problem in the generated .o file. (Comments #3 and #4 > > have the new material.) > > > > My guess is that FreeBSD Bugzilla 215819 should no longer > > be assigned to freebsd-toolchain@FreeBSD.org . Instead it > > would be a powerpc64 kernel source code issue if I'm right. > > > > Ed Maste or someone like that likely would make this final > > decision as well. > > > > === > > Mark Millard > > markmi at dsl-only.net > > > > On 2017-Jan-7, at 3:12 PM, Mark Millard <markmi at dsl-only.net> wrote: > > > >> [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 <markmi at dsl-only.net> wrote: > >> > >>> On 2017-Jan-7, at 12:51 AM, Roman Divacky <rdivacky at vlakno.cz> 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 and recompile the kernel? That should > >>>> remove > >>>> this llvm assembly problem. Does it boot? > >>>> > >>>> Thanks Mark, really great progress. > >>>> > >>>> Roman > >>> > >>> In attempting this 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 criteria for > >>> gcc compatibility relative to filling-in/defaulting omitted > >>> @toc's in the assembler notation. > >>> > >>> FreeBSD has the option of always being explicit with @toc in order > >>> to avoid differences in handling of omitted notation. > >>> > >>> So I've no clue if FreebSD wants to claim that a llvm change > >>> is a requirement for using clang as the powerpc64 system compiler. > >>> > >>> [The issue of the distinction is submittable to llvm either way.] > >>> > >>> Details. . . > >>> > >>> For: > >>> > >>> .section ".toc","aw" > >>> tmpstk.L: .tc tmpstk[TC],tmpstk > >>> . . . > >>> /* Set up the stack pointer */ > >>> ld %r1,tmpstk.L(%r2) > >>> > >>> using devel/powerpc64-gcc gets: > >>> > >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ > >>> > >>> > >>> -c \ > >>> > >>> > >>> > >>> -x assembler-with-cpp \ > >>> > >>> > >>> > >>> -pipe \ > >>> > >>> > > > > >> > >>> > >>> locore64_simplified.S > >>> locore64_simplified.S: Assembler messages: > >>> locore64_simplified.S:80: Warning: assuming @toc on symbol > >>> > >>> and produces (with R_PPC64_TOC16_DS for .toc): > >>> > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o > >>> > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>> > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_TOC16_DS .toc > >>> > >>> > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>> > >>> > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>> > >>> > >>> By contrast clang is silent (cross compiler used): > >>> > >>> # > >>> /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/cc > >>> \ > >>> > >>> -target > >>> powerpc64-unknown-freebsd12.0 \ > >>> > >>> > >>> > >>> --sysroot=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp > >>> \ > >>> > >>> > >>> -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin > >>> \ > >>> > > > > >> > >>> > >>> -c \ > >>> > >>> > >>> -x > >>> assembler-with-cpp \ > >>> > >>> > >>> -pipe \ > >>> > >>> > >>> > >>> locore64_simplified.S > >>> > >>> and produces code with R_PPC64_ADDR16_DS for the .toc instead: > >>> > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | > >>> more > >>> > >>> > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>> > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_ADDR16_DS .toc > >>> > >>> > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>> > >>> > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>> > >>> > >>> > >>> But for: > >>> > >>> .section ".toc","aw" > >>> tmpstk.L: .tc tmpstk[TC],tmpstk > >>> . . . > >>> /* Set up the stack pointer */ > >>> ld %r1,tmpstk.L@toc(%r2) > >>> > >>> (note the @toc notation) both compilers agree and use > >>> R_PPC64_TOC16_DS for the .toc: > >>> > >>> # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc \ > >>> > >>> > >>> -c \ > >>> > >>> > >>> > >>> -x assembler-with-cpp \ > >>> > >>> > >>> > >>> -pipe \ > >>> > >>> > > > > >> > >>> > >>> locore64_simplified.S > >>> > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | > >>> more > >>> > >>> > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>> > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_TOC16_DS .toc > >>> > >>> > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>> > >>> > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>> > >>> > >>> # > >>> /usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin/cc > >>> \ > >>> > >>> -target > >>> powerpc64-unknown-freebsd12.0 \ > >>> > >>> > >>> > >>> --sysroot=/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp > >>> \ > >>> > >>> > >>> -B/usr/obj/powerpc64vtsc_clang_kernel/powerpc.powerpc64/usr/src/tmp/usr/bin > >>> \ > >>> > > > > >> > >>> > >>> -c \ > >>> > >>> > >>> -x > >>> assembler-with-cpp \ > >>> > >>> > >>> -pipe \ > >>> > >>> > >>> > >>> locore64_simplified.S > >>> > >>> # /usr/local/powerpc64-freebsd/bin/objdump -r locore64_simplified.o | > >>> more > >>> > >>> > >>> locore64_simplified.o: file format elf64-powerpc-freebsd > >>> > >>> RELOCATION RECORDS FOR [.text]: > >>> OFFSET TYPE VALUE > >>> 0000000000000028 R_PPC64_REL64 __tocbase+0x0000000000008000 > >>> 0000000000000046 R_PPC64_TOC16_DS .toc > >>> > >>> > >>> RELOCATION RECORDS FOR [.toc]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 tmpstk > >>> > >>> > >>> RELOCATION RECORDS FOR [.opd]: > >>> OFFSET TYPE VALUE > >>> 0000000000000000 R_PPC64_ADDR64 .__start > >>> 0000000000000008 R_PPC64_TOC *ABS* > >>> > >>> > >>> > >>> I omitted "-f -gdwarf-2" to simplify things but with such > >>> clang complains about: > >>> > >>> locore64_simplified.S:36:2: warning: DWARF2 only supports one section per > >>> compilation unit > >>> .section ".toc","aw" > >>> ^ > >>> locore64_simplified.S:47:2: warning: DWARF2 only supports one section per > >>> compilation unit > >>> .section ".opd","aw" > >>> ^ > >>> > >>> (buildkernel gets such messages.) > >>> > >>> > >>> I expect I can simplify the .S code more than I have so far but > >>> I figured I'd report the discovery of the choice FreeBSD needs > >>> to make for powerpc64 for if llvm changes are to be required > >>> vs. not. > >> > >> The following should be a list of the places that adding @toc usage > >> would fix some things for using clang 3.9.1 to target powerpc64: > >> > >> # grep "@toc[^b]" > >> /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolchain_kernel-amd64-host-2017-01-03:23:48:41 > >> | more > >> /usr/src/sys/powerpc/aim/locore64.S:102: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/aim/trap_subr64.S:320: Warning: assuming @toc on > >> symbol > >> /usr/src/sys/powerpc/aim/trap_subr64.S:797: Warning: assuming @toc on > >> symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:104: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:108: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:116: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:226: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:228: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/ofw/ofwcall64.S:235: Warning: assuming @toc on symbol > >> /usr/src/sys/powerpc/powerpc/swtch64.S:153: Warning: assuming @toc on > >> symbol > >> > >> devel/powerpc64-gcc and devel/powerpc64-binutils together happens to report > >> on missing @toc 's. > >> > >> But, of course, if some sections of code are conditionally compiled and > >> excluded above they would not be listed. > >> > >> === > >> 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" > > _______________________________________________ > 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" _______________________________________________ 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"
