clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . .

Roman Divacky rdivacky at vlakno.cz
Wed Dec 7 19:03:33 UTC 2016


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.

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 -Wno-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-ppc at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc
> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe at freebsd.org"


More information about the freebsd-ppc mailing list