Date: Thu, 8 Dec 2016 19:55:41 +0100 From: Roman Divacky <rdivacky@vlakno.cz> To: Mark Millard <markmi@dsl-only.net> Cc: FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, Justin Hibbits <chmeeedalf@gmail.com>, FreeBSD PowerPC ML <freebsd-ppc@freebsd.org> Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20161208185541.GA33364@vlakno.cz> In-Reply-To: <CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <D3DE2D12-9885-4154-B680-6DA5A8B62A56@dsl-only.net> <D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net> <CE88C1F4-B9BD-4D45-8DF0-F1079C3257A5@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Can you try to investigate why it dies? I am not convinced -mminimal-toc would result in a boot failure. I think the kernel would fail to link. On Wed, Dec 07, 2016 at 09:52:47PM -0800, Mark Millard wrote: > Top post of a FYI [head -r309656 powerpc64 context]: >=20 > I commented out the one -mminimal-toc use in the modules and tried > buildkernel again (cross build). >=20 > It reached the end. But it dies immediately if I try to > boot it after installing a copy. >=20 > This was based on: >=20 > # svnlite diff /usr/src/sys/modules/zfs/Makefile > Index: /usr/src/sys/modules/zfs/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/modules/zfs/Makefile (revision 309656) > +++ /usr/src/sys/modules/zfs/Makefile (working copy) > @@ -93,9 +93,9 @@ > CFLAGS+=3D-I${SUNW}/common > CFLAGS+=3D-DBUILDING_ZFS > =20 > -.if ${MACHINE_ARCH} =3D=3D "powerpc64" > -CFLAGS+=3D-mminimal-toc > -.endif > +#.if ${MACHINE_ARCH} =3D=3D "powerpc64" > +#CFLAGS+=3D-mminimal-toc > +#.endif > =20 > .ifdef ZFS_DEBUG > CFLAGS+=3D-DDEBUG=3D1 >=20 > as well as your .td file patch. >=20 > zfs is not in use in the configuration: it just > uses ufs. >=20 > I'll note that I had avoided 2.47 binutils variants > based on reported issues in powerpc land (not that > I know the details or the powerpc64 vs. powerpc vs. > both status of the issues). >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On 2016-Dec-7, at 4:11 PM, Mark Millard <markmi@dsl-only.net> wrote: >=20 > On 2016-Dec-7, at 11:00 AM, Roman Divacky <rdivacky at vlakno.cz> wrote: >=20 > > Can the compiler you built with the patch process this file: > >=20 > > typedef int register_t; > > #define mtpmr(reg, val) = \ > > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > > #define mfpmr(reg) = \ > > ( { register_t val; \ > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); = \ > > val; } ) > >=20 > > #define PMR_PMC0 16 > >=20 > > int foo() > > { > > return mfpmr(PMR_PMC0); > > } > >=20 > >=20 > > I can compile it just fine locally. Not sure why it wouldnt work in you= r case. >=20 > I separately had helped with testing for bugzilla 214902 > and so had updated to head -r309656 so the context was > different. >=20 > But I figured out the .td file related issue on powerpc64. >=20 > My means of forcing all the compiles that target powerpc64 > to use -B to pick up the alternate toolchain (since the > bootstrap binutils ld can fail) also forced the system > compiler to be used instead of the bootstrapped clang. > (The SRC_CONF_ENV file that I used had the text that > forced this.) >=20 > So my buildkernel was using an unpatched compiler when > I tried kernel-toolchain then buildkernel. >=20 > This was visible in the .meta file part of my report on the > problem. It showed: >=20 > > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ >=20 >=20 > instead of having the path to the bootstrap compiler. >=20 > It turns out that my amd64 cross build SRC_CONF_ENV file > also had remnants of an experiment that also happened to > force the system compiler to be used so it would have got > the same behavior. >=20 > Based on use of compilers that actually have your > patch in them. . . >=20 > Your patch worked fine to let the buildkernel reach > the next problem: use of -mminimial-toc in a kernel > module is made but is rejected for powerpc64. >=20 > Sorry for the extra noise in reporting on your patch. >=20 >=20 > Trying to find new things to report (future problems) > by working around existing problems that are known but > unfixed tends to have these sorts of interferences. Of > course sometimes my workarounds might not be the best > ones available. >=20 > This stupid mistake is probably what is going on in > at least one bugzilla report that I submitted: So > I've likely got more to clean up. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > Older material. . . >=20 > On Mon, Dec 05, 2016 at 05:42:28PM -0800, Mark Millard wrote: > > On 2016-Dec-5, at 5:16 PM, Mark Millard <markmi at dsl-only.net> wrote: > >=20 > >> Well it looks like: > >>=20 > >> WITHOUT_CROSS_COMPILER=3D > >> WITH_SYSTEM_COMPILER=3D > >>=20 > >> ignores the .td file change but > >>=20 > >> WITH_CROSS_COMPILER=3D > >> WITHOUT_SYSTEM_COMPILER=3D > >>=20 > >> may use it. > >>=20 > >> I had accidentally used a SRC_CONF_ENV file that > >> was of the first form. > >>=20 > >> So I've got a build going based on the 2nd form. . . > >=20 > > No such luck: same type of failure at the same point. > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net > >=20 > > On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> wrote: > >=20 > > On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote: > >=20 > >> Can you try this patch? > >>=20 > >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > >> +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > >> @@ -2373,6 +2373,12 @@ > >> def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > >> "mftb $RT, $SPR", IIC_SprMFTB>; > >>=20 > >> +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 =3D 1, usesCustomInserter =3D 1 in > >=20 > > Direct use of the patch (put into a file) was rejected: > >=20 > > # patch -p0 < llvmPPCInstrInfo_td.patch=20 > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -------------------------- > > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > |--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > |+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > -------------------------- > > Patching file llvm/lib/Target/PowerPC/PPCInstrInfo.td using Plan A... > > patch: **** malformed patch at line 6: def MFTB : XFXForm_1<31, 371, (o= uts gprc:$RT), (ins i32imm:$SPR), > >=20 > > So I hand put in the extra lines. > >=20 > > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124 > > the MFTB line is at line number 2300 while your patch listed: > >=20 > > @@ -2373,6 +2373,12 @@ > >=20 > > My edit shows as: > >=20 > > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > --- contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 309179) > > +++ contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > @@ -2300,6 +2300,12 @@ > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > "mftb $RT, $SPR", IIC_SprMFTB>; > >=20 > > +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 =3D 1, usesCustomInserter =3D 1 in > >=20 > >=20 > > Unfortunately the buildkernel still gets the same errors: > > (This was tried after a kernel-toolchain .) > >=20 > > # Meta data file /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerp= c.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwp= mc/hwpmc_e500.o.meta > > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target powerpc= 64-unknown-freebsd12.0 --sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils= _kernel/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -= O2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KE= RNEL_OPTION_HEADERS -include /usr/obj/powerpc64vtsc_clang_altbinutils_kerne= l/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/opt_global.h -I. -I/usr= /src/sys -fno-common -g -fno-omit-frame-pointer -I/usr/obj/powerpc64vtsc_cl= ang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG -= mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredu= ndant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoi= nter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__= freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unk= nown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-err= or-parentheses-equality -Wno-e > > rror-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-= value -msoft-float -std=3Diso9899:1999 -c /usr/src/sys/modules/hwpmc/../.= =2E/dev/hwpmc/hwpmc_e500.c -o hwpmc_e500.o > > CMD ctfconvert -L VERSION -g hwpmc_e500.o > > CWD /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/u= sr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc > > TARGET hwpmc_e500.o > > -- command output -- > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error: = unrecognized instruction mnemonic > > uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > > ^ > > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > > ^ > > <inline asm>:1:2: note: instantiated into assembly here > > mfpmr 3,400 > > ^ > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:478:2: error: u= nrecognized instruction mnemonic > > mtpmr(PMR_PMGC0, pmgc0); > > ^ > > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > > ^ > > <inline asm>:1:2: note: instantiated into assembly here > > mtpmr 400,3 > > ^ > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:446:2: error: u= nrecognized instruction mnemonic > > mtpmr(PMR_PMGC0, PMGC_FAC | PMGC_PMIE | PMGC_FCECE); > > ^ > > ./machine/pmc_mdep.h:21:19: note: expanded from macro 'mtpmr' > > __asm __volatile("mtpmr %0,%1" : : "K"(reg), "r"(val)) > > ^ > > <inline asm>:1:2: note: instantiated into assembly here > > mtpmr 400,3 > > ^ > > /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:408:14: error: = unrecognized instruction mnemonic > > pmc_pmlc =3D mfpmr(PMR_PMLCa0); > > ^ > > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > > __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > > ^ > > <inline asm>:1:2: note: instantiated into assembly here > > mfpmr 10,144 > > ^ > > . . . > >=20 > >=20 > > =3D=3D=3D > > Mark Millard > > markmi at dsl-only.net > >=20 > > Older content: > >=20 > > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote: > >> [Note: At present I can buildworld using WITH_LIB32=3D on > >> powerpc64 for TARGET_ARCH=3Dpowerpc64 via clang 3.9.0 from a > >> minor variant of head -r309179 . That does not work for > >> amd64 cross compiling to powerpc64 due to assembler > >> notation rejections.] > >>=20 > >> When I attempt to buildkernel (with WERROR=3D ) via FreeBSD's > >> clang 3.9.0 I get the following sorts of error > >> reports, *even building on powerpc64* : > >>=20 > >> --- hwpmc_e500.o --- > >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error:= unrecognized instruction mnemonic > >> uint32_t pmgc0 =3D mfpmr(PMR_PMGC0); > >> ^ > >> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr' > >> __asm __volatile("mfpmr %0,%1" : "=3Dr"(val) : "K"(reg)); \ > >> ^ > >> <inline asm>:1:2: note: instantiated into assembly here > >> mfpmr 3,400 > >> ^ > >> . . . > >>=20 > >> When I look up these instructions I find that they are not > >> classic powerpc instructions: > >> ( http://www.nxp.com/assets/documents/data/en/white-papers/POWRPCARCPR= MRM.pdf ) > >>=20 > >>> Whereas the classic architecture defines special-purpose registers (S= PRs) and > >>> two instructions to access them (Move to Special-Purpose Register (mt= spr) and > >>> Move from Special-Purpose Register (mfspr)), Book E takes that model = and defines > >>> optional device control registers (DCRs) and mtdcr and mfdcr instruct= ions, and > >>> the EIS-defined performance monitor APU defines performance monitor r= egisters > >>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided= by the > >>> UISA. > >>=20 > >> . . . > >>=20 > >> Does this imply that clang 3.9.0 needs to support more instructions wh= en > >> it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC= 64 > >> and then override some items for my build activity.) > >>=20 > >> If yes, then someone probably needs to make a list of what instructions > >> need to be present and have someone submit the list into llvm's bugzil= la > >> and have the submittal listed in: > >>=20 > >> [META] Using Clang as the FreeBSD/ppc system compiler > >>=20 > >> (25780). > >>=20 > >>=20 > >> If GENERIC64 does not need the likes of hwpmc_e500.o built then some > >> work on the build environment to avoid GENERIC64 including things with > >> non-classic instruction use would appear to be needed. (No llvm > >> involvement for this case.) I doubt this is the case as it would > >> seem that the problem would reoccur when alternate KERNCONF's were > >> in use instead that do require something like of hwpmc_e500.o to be > >> built. > >>=20 > >>=20 > >> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214903 is ab= out > >> this issue from the FreeBSD side of things. I just noticed the status > >> of the specific instructions involved and also that the cross-build > >> and on-powerpc64 build get the same result (unlike the recent > >> WITH_LIB32=3D discovery). > >>=20 > >> =3D=3D=3D > >> Mark Millard > >> markmi at dsl-only.net > >=20 > >=20 > > _______________________________________________ > > freebsd-ppc@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161208185541.GA33364>