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]:
>
> I commented out the one -mminimal-toc use in the modules and tried
> buildkernel again (cross build).
>
> It reached the end. But it dies immediately if I try to
> boot it after installing a copy.
>
> This was based on:
>
> # svnlite diff /usr/src/sys/modules/zfs/Makefile
> Index: /usr/src/sys/modules/zfs/Makefile
> ===================================================================
> --- /usr/src/sys/modules/zfs/Makefile (revision 309656)
> +++ /usr/src/sys/modules/zfs/Makefile (working copy)
> @@ -93,9 +93,9 @@
> CFLAGS+=-I${SUNW}/common
> CFLAGS+=-DBUILDING_ZFS
>
> -.if ${MACHINE_ARCH} == "powerpc64"
> -CFLAGS+=-mminimal-toc
> -.endif
> +#.if ${MACHINE_ARCH} == "powerpc64"
> +#CFLAGS+=-mminimal-toc
> +#.endif
>
> .ifdef ZFS_DEBUG
> CFLAGS+=-DDEBUG=1
>
> as well as your .td file patch.
>
> zfs is not in use in the configuration: it just
> uses ufs.
>
> 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).
>
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> On 2016-Dec-7, at 4:11 PM, Mark Millard <mar...@dsl-only.net> wrote:
>
> On 2016-Dec-7, at 11:00 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
>
> > Can the compiler you built with the patch process this file:
> >
> > 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" : "=r"(val) : "K"(reg)); \
> > val; } )
> >
> > #define PMR_PMC0 16
> >
> > int foo()
> > {
> > return mfpmr(PMR_PMC0);
> > }
> >
> >
> > I can compile it just fine locally. Not sure why it wouldnt work in your
> > case.
>
> I separately had helped with testing for bugzilla 214902
> and so had updated to head -r309656 so the context was
> different.
>
> But I figured out the .td file related issue on powerpc64.
>
> 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.)
>
> So my buildkernel was using an unpatched compiler when
> I tried kernel-toolchain then buildkernel.
>
> This was visible in the .meta file part of my report on the
> problem. It showed:
>
> > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/
>
>
> instead of having the path to the bootstrap compiler.
>
> 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.
>
> Based on use of compilers that actually have your
> patch in them. . .
>
> 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.
>
> Sorry for the extra noise in reporting on your patch.
>
>
> 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.
>
> 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.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> Older material. . .
>
> 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:
> >
> >> Well it looks like:
> >>
> >> WITHOUT_CROSS_COMPILER=
> >> WITH_SYSTEM_COMPILER=
> >>
> >> ignores the .td file change but
> >>
> >> WITH_CROSS_COMPILER=
> >> WITHOUT_SYSTEM_COMPILER=
> >>
> >> may use it.
> >>
> >> I had accidentally used a SRC_CONF_ENV file that
> >> was of the first form.
> >>
> >> So I've got a build going based on the 2nd form. . .
> >
> > No such luck: same type of failure at the same point.
> >
> > ===
> > Mark Millard
> > markmi at dsl-only.net
> >
> > On 2016-Dec-5, at 4:05 PM, Mark Millard <markmi at dsl-only.net> wrote:
> >
> > On 2016-Dec-5, at 8:19 AM, Roman Divacky <rdivacky at vlakno.cz> wrote:
> >
> >> Can you try this patch?
> >>
> >> Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> >> ===================================================================
> >> --- 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>;
> >>
> >> +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
> >
> > Direct use of the patch (put into a file) was rejected:
> >
> > # patch -p0 < llvmPPCInstrInfo_td.patch
> > Hmm... Looks like a unified diff to me...
> > The text leading up to this was:
> > --------------------------
> > |Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > |===================================================================
> > |--- 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, (outs
> > gprc:$RT), (ins i32imm:$SPR),
> >
> > So I hand put in the extra lines.
> >
> > I'll note that in llvm/lib/Target/PowerPC/PPCInstrInfo.td -r309124
> > the MFTB line is at line number 2300 while your patch listed:
> >
> > @@ -2373,6 +2373,12 @@
> >
> > My edit shows as:
> >
> > # svnlite diff contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > Index: contrib/llvm/lib/Target/PowerPC/PPCInstrInfo.td
> > ===================================================================
> > --- 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>;
> >
> > +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
> >
> >
> > Unfortunately the buildkernel still gets the same errors:
> > (This was tried after a kernel-toolchain .)
> >
> > # Meta data file
> > /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.meta
> > CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target
> > powerpc64-unknown-freebsd12.0
> > --sysroot=/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_KERNEL_OPTION_HEADERS -include
> > /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/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_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG
> > -mno-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall
> > -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
> > -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign
> > -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> > -fdiagnostics-show-option -Wno-unknown-pragmas
> > -Wno-error-tautological-compare -Wno-error-empty-body
> > -Wno-error-parentheses-equality -Wn
o-e
> > rror-unused-function -Wno-error-pointer-sign
> > -Wno-error-shift-negative-value -msoft-float -std=iso9899:1999 -c
> > /usr/src/sys/modules/hwpmc/../../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/usr/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 = mfpmr(PMR_PMGC0);
> > ^
> > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> > __asm __volatile("mfpmr %0,%1" : "=r"(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:
> > unrecognized 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:
> > unrecognized 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 = mfpmr(PMR_PMLCa0);
> > ^
> > ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> > __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg)); \
> > ^
> > <inline asm>:1:2: note: instantiated into assembly here
> > mfpmr 10,144
> > ^
> > . . .
> >
> >
> > ===
> > Mark Millard
> > markmi at dsl-only.net
> >
> > Older content:
> >
> > On Sat, Dec 03, 2016 at 08:35:50PM -0800, Mark Millard wrote:
> >> [Note: At present I can buildworld using WITH_LIB32= on
> >> powerpc64 for TARGET_ARCH=powerpc64 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.]
> >>
> >> When I attempt to buildkernel (with WERROR= ) via FreeBSD's
> >> clang 3.9.0 I get the following sorts of error
> >> reports, *even building on powerpc64* :
> >>
> >> --- hwpmc_e500.o ---
> >> /usr/src/sys/modules/hwpmc/../../dev/hwpmc/hwpmc_e500.c:475:19: error:
> >> unrecognized instruction mnemonic
> >> uint32_t pmgc0 = mfpmr(PMR_PMGC0);
> >> ^
> >> ./machine/pmc_mdep.h:24:21: note: expanded from macro 'mfpmr'
> >> __asm __volatile("mfpmr %0,%1" : "=r"(val) : "K"(reg)); \
> >> ^
> >> <inline asm>:1:2: note: instantiated into assembly here
> >> mfpmr 3,400
> >> ^
> >> . . .
> >>
> >> 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/POWRPCARCPRMRM.pdf
> >> )
> >>
> >>> Whereas the classic architecture defines special-purpose registers (SPRs)
> >>> and
> >>> two instructions to access them (Move to Special-Purpose Register (mtspr)
> >>> and
> >>> Move from Special-Purpose Register (mfspr)), Book E takes that model and
> >>> defines
> >>> optional device control registers (DCRs) and mtdcr and mfdcr
> >>> instructions, and
> >>> the EIS-defined performance monitor APU defines performance monitor
> >>> registers
> >>> (PMRs) and mtpmr and mfpmr instructions, all based on models provided by
> >>> the
> >>> UISA.
> >>
> >> . . .
> >>
> >> Does this imply that clang 3.9.0 needs to support more instructions when
> >> it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64
> >> and then override some items for my build activity.)
> >>
> >> 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 bugzilla
> >> and have the submittal listed in:
> >>
> >> [META] Using Clang as the FreeBSD/ppc system compiler
> >>
> >> (25780).
> >>
> >>
> >> 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.
> >>
> >>
> >> Note: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214903 is about
> >> 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= discovery).
> >>
> >> ===
> >> Mark Millard
> >> markmi at dsl-only.net
> >
> >
> > _______________________________________________
> > freebsd-...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> > To unsubscribe, send any mail to "freebsd-ppc-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"
