I have added the patches to my various historical submittals and submitted some I'd never made submittals for.
For the sys/modules/zfs/Makefile I eliminated the extra blank line that was added in what I showed earlier for the patches. Some of the patches are tied to allowing all 3 types of buidlworld buildkernel contexts in Makefile* 's for one or both of powerpc64 and powerpc: 0) system gcc 4.2.1 and (bootstrapped) system binutils (not libc++ based) 1) devel/powerpc64-xtoolchain-gcc devel/powerpc64-gcc devel/powerpc64-binutils (libc++ based, no lib32) 2) system clang and devel/powerpc64-binutils or (bootstrapped) system binutils (One(?) driven by 3.8.0 that would not be needed for 3.9.1) (libc++ based) Some contexts require options that the others do not. Some contexts require options that others do not allow and do not need. Some I added note to about potentially using CFLAGS.gcc+= and CFLAGS.clang+= instead of conditional logic if the contexts allow such to be effective. The bugzilla numbers (if I found them all): 205455 206303 214904 (the patch allowed building but is not a complete clang/llvm update) 215107 215681 215819 215947 215948 Generally this list excludes things for which WERROR= allows the buildkernel attempts to complete and things related to restrictions like avoiding lib32 for devel/powerpc64-gcc based builds. === Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 9:34 PM, Mark Millard <[email protected]> wrote: I'll note that: Bug 214855 - head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error means that I can not use the bootstrap binutils to do buildworld for powerpc64. I've confirmed that it still happens in -r311147 . So to span both buildkernel and buildworld does require devel/powerpc64-binutils or the like for TARGET_ARCH=powerpc64 . === Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 4:40 PM, Mark Millard <markmi at dsl-only.net> wrote: [I've not tried lldb yet but I have good news. . .] Well it turns out I was wrong: after the @toc changes (now in the TOC_REF(...) macro instead of per instruction) I can boot a kernel built using the bootstrap system binutils and clang as well. devel/powerpc64-binutils or the like is not required. It looks like bugzilla 215821 is wrong/redundant and 215819 actually covers the issue. I will likely close 215821 after I've played around some more. I can build with clang 3.9.1, devel/powerpc64-xtoolchain-gcc, or gcc 4.2.1 as I have things. clang 3.9.1 based builds do not handle throwing C++ exceptions. lib32 does not work for devel/powerpc64-gcc based builds. As stands I have head -r311147 with: # svnlite status /usr/src/ | sort ? /usr/src/sys/amd64/conf/GENERIC-DBG ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/arm/conf/BPIM3-DBG ? /usr/src/sys/arm/conf/BPIM3-NODBG ? /usr/src/sys/arm/conf/RPI2-DBG ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm64/conf/GENERIC-DBG ? /usr/src/sys/arm64/conf/GENERIC-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-DBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-DBG ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODBG M /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td M /usr/src/lib/csu/powerpc64/Makefile M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk M /usr/src/sys/ddb/db_main.c (Not relevant) M /usr/src/sys/ddb/db_script.c (Not relevant) M /usr/src/sys/modules/zfs/Makefile M /usr/src/sys/powerpc/aim/trap_subr32.S M /usr/src/sys/powerpc/include/asm.h M /usr/src/sys/powerpc/ofw/ofw_machdep.c (Not relevant) The various KERNCONF's include standard ones then adjust things. They are not otherwise relevant. Notes on the differences ("M" lines): [I do not have a context to test powerpc's kboot or uboot for powerpc or powerpc64: only PowerMacs. Those Makefile changes were based on avoiding build errors that occurred before the change (long ago). I've not gone back through the armv6(/v7) and arm64 builds recently but historically they have worked on the rpi2, bpim3, and pine64 with the boot/uboot/Makefile.inc change in place.] llvm/lib/Target/PowerPC/PPCInstrInfo.td is Roman D.'s incomplete patch for the e500 instructions. It was sufficient to let me continue. The various Makefile*'s and *.mk's deal with: -mlongcall (gcc) vs. not (clang) -m elf32ppc_fbsd (old) vs. -Wl,-m -Wl,elf32ppc_fbsd (new) -mcpu=powerpc64 and -Wa,-mppc64bridge in a Makefile (kboot) that TARGET_ARCH=powerpc tried to build and failed: delete the usage of these options. (No test validation of built kboot result!) -Wa,many for gcc vs. no-such for clang sys/conf/kern.mk deals with: -mllvm -disable-ppc-float-in-variadic=true (older clang) vs. -msoft-float (newer clang) sys/modules/zfs/Makefile deals with: -mminimial-toc (gcc) vs. no-such (clang) sys/ddb/db_main.c and sys/ddb/db_script.c : These would not be included. (They set up to execute a built-in default script so I get information for early boot issues from before ddb takes input.) sys/powerpc/aim/trap_subr32.S deals with: Have a cmp instruction be explicit by adding a "0, ". (This is a TARGET_ARCH=powerpc issue, not a TARGET_ARCH=powerpc64 issue.) sys/powerpc/include/asm.h deals with: Have TOC_REF(...) also include @toc in the notation that results. Have a TOC_NAME_FOR_REF(...) that only adds the .L to the name passed in and use it where appropriate. sys/powerpc/ofw/ofw_machdep.c : This would not be included. (It is a PowerMac G5 specific workaround for a openfirmware vs. FreeBSD conflict that makes booting unreliable for standard FreeBSD builds.) The details that are not driven by PowerMac G5 specifics look like: Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td =================================================================== --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 311147) +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) @@ -2336,6 +2336,12 @@ def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), "mftb $RT, $SPR", IIC_SprMFTB>; +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), + "mfpmr $RT, $PMRN", IIC_IntGeneral>; + +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), + "mtpmr $PMRN, $RS", IIC_IntGeneral>; + // A pseudo-instruction used to implement the read of the 64-bit cycle counter // on a 32-bit target. let hasSideEffects = 1, usesCustomInserter = 1 in Index: /usr/src/lib/csu/powerpc64/Makefile =================================================================== --- /usr/src/lib/csu/powerpc64/Makefile (revision 311147) +++ /usr/src/lib/csu/powerpc64/Makefile (working copy) @@ -5,19 +5,20 @@ SRCS= crt1.c crti.S crtn.S OBJS= ${SRCS:N*.h:R:S/$/.o/g} OBJS+= Scrt1.o gcrt1.o +.include <bsd.compiler.mk> +.if ${COMPILER_TYPE} == "gcc" CFLAGS+= -I${.CURDIR}/../common \ -I${.CURDIR}/../../libc/include \ -mlongcall +.else +CFLAGS+= -I${.CURDIR}/../common \ + -I${.CURDIR}/../../libc/include +.endif # XXX: See the log for r232932 as to why the above -mlongcall is needed. Since # clang doesn't support -mlongcall, and testing shows a clang linked with a # clang-built csu segfaults, this must currently be compiled with gcc. Once # clang supports -mlongcall, or we get a fixed ld, this can be revisited. -.include <bsd.compiler.mk> -.if ${COMPILER_TYPE} != "gcc" -CC:= gcc -COMPILER_TYPE:= gcc -.endif FILES= ${OBJS} FILESMODE= ${LIBMODE} Index: /usr/src/sys/boot/ofw/Makefile.inc =================================================================== --- /usr/src/sys/boot/ofw/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/ofw/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} == "powerpc64" CFLAGS+= -m32 -mcpu=powerpc -LDFLAGS+= -m elf32ppc_fbsd +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/Makefile.inc =================================================================== --- /usr/src/sys/boot/powerpc/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/powerpc/Makefile.inc (working copy) @@ -2,6 +2,7 @@ .if ${MACHINE_ARCH} == "powerpc64" CFLAGS+= -m32 -mcpu=powerpc +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/boot/powerpc/kboot/Makefile =================================================================== --- /usr/src/sys/boot/powerpc/kboot/Makefile (revision 311147) +++ /usr/src/sys/boot/powerpc/kboot/Makefile (working copy) @@ -68,8 +68,6 @@ LIBFICL= ${.OBJDIR}/../../ficl/libficl.a .endif -CFLAGS+= -mcpu=powerpc64 - # Always add MI sources .PATH: ${.CURDIR}/../../common ${.CURDIR}/../../../libkern .include "${.CURDIR}/../../common/Makefile.inc" @@ -85,9 +83,6 @@ LDFLAGS= -nostdlib -static -T ${.CURDIR}/ldscript.powerpc -# 64-bit bridge extensions -CFLAGS+= -Wa,-mppc64bridge - # Pull in common loader code #.PATH: ${.CURDIR}/../../ofw/common #.include "${.CURDIR}/../../ofw/common/Makefile.inc" Index: /usr/src/sys/boot/uboot/Makefile.inc =================================================================== --- /usr/src/sys/boot/uboot/Makefile.inc (revision 311147) +++ /usr/src/sys/boot/uboot/Makefile.inc (working copy) @@ -2,7 +2,7 @@ .if ${MACHINE_ARCH} == "powerpc64" CFLAGS+= -m32 -mcpu=powerpc -LDFLAGS+= -m elf32ppc_fbsd +LDFLAGS+= -Wl,-m -Wl,elf32ppc_fbsd .endif .include "../Makefile.inc" Index: /usr/src/sys/conf/Makefile.powerpc =================================================================== --- /usr/src/sys/conf/Makefile.powerpc (revision 311147) +++ /usr/src/sys/conf/Makefile.powerpc (working copy) @@ -39,7 +39,11 @@ # Force __SPE__, since the builtin will be removed later with -mno-spe CFLAGS+= -mabi=spe -D__SPE__ .endif +.if ${COMPILER_TYPE} == "gcc" CFLAGS+= -msoft-float -Wa,-many +.else +CFLAGS+= -msoft-float +.endif # Build position-independent kernel CFLAGS+= -fPIC Index: /usr/src/sys/conf/kern.mk =================================================================== --- /usr/src/sys/conf/kern.mk (revision 311147) +++ /usr/src/sys/conf/kern.mk (working copy) @@ -162,7 +162,11 @@ # .if ${MACHINE_CPUARCH} == "powerpc" CFLAGS+= -mno-altivec +.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 30800 CFLAGS.clang+= -mllvm -disable-ppc-float-in-variadic=true +.else +CFLAGS.clang+= -msoft-float +.endif CFLAGS.gcc+= -msoft-float INLINE_LIMIT?= 15000 .endif Index: /usr/src/sys/conf/kmod.mk =================================================================== --- /usr/src/sys/conf/kmod.mk (revision 311147) +++ /usr/src/sys/conf/kmod.mk (working copy) @@ -147,8 +147,12 @@ .endif .if ${MACHINE_CPUARCH} == powerpc +.if ${COMPILER_TYPE} == "gcc" CFLAGS+= -mlongcall -fno-omit-frame-pointer +.else +CFLAGS+= -fno-omit-frame-pointer .endif +.endif .if ${MACHINE_CPUARCH} == mips CFLAGS+= -G0 -fno-pic -mno-abicalls -mlong-calls Index: /usr/src/sys/modules/zfs/Makefile =================================================================== --- /usr/src/sys/modules/zfs/Makefile (revision 311147) +++ /usr/src/sys/modules/zfs/Makefile (working copy) @@ -93,9 +93,16 @@ CFLAGS+=-I${SUNW}/common CFLAGS+=-DBUILDING_ZFS + .if ${MACHINE_ARCH} == "powerpc64" +.include <bsd.compiler.mk> +.if ${COMPILER_TYPE} == "gcc" +# gcc421 requires the -mminimal-toc . +# But clang 3.9.1 disallows it and does not need it. +# more modern gcc's allow it. CFLAGS+=-mminimal-toc .endif +.endif .ifdef ZFS_DEBUG CFLAGS+=-DDEBUG=1 Index: /usr/src/sys/powerpc/aim/trap_subr32.S =================================================================== --- /usr/src/sys/powerpc/aim/trap_subr32.S (revision 311147) +++ /usr/src/sys/powerpc/aim/trap_subr32.S (working copy) @@ -406,7 +406,7 @@ mtctr %r1 /* load counter */ im1: lwzu %r1, 8(%r2) /* get next pte */ - cmp 0, %r1, %r3 /* see if found pte */ + cmp 0, 0, %r1, %r3 /* see if found pte */ bdnzf 2, im1 /* dec count br if cmp ne and if * count not zero */ bne instr_sec_hash /* if not found set up second hash Index: /usr/src/sys/powerpc/include/asm.h =================================================================== --- /usr/src/sys/powerpc/include/asm.h (revision 311147) +++ /usr/src/sys/powerpc/include/asm.h (working copy) @@ -89,10 +89,11 @@ name: #ifdef __powerpc64__ -#define TOC_REF(name) __CONCAT(.L,name) +#define TOC_NAME_FOR_REF(name) __CONCAT(.L,name) +#define TOC_REF(name) TOC_NAME_FOR_REF(name)@toc #define TOC_ENTRY(name) \ .section ".toc","aw"; \ - TOC_REF(name): \ + TOC_NAME_FOR_REF(name): \ .tc name[TC],name #endif === Mark Millard markmi at dsl-only.net On 2017-Jan-8, at 6:41 AM, Roman Divacky <[email protected]> wrote: 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 [email protected] . 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 >> >> _______________________________________________ >> [email protected] mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to "[email protected]" > > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
