Date: Wed, 7 Dec 2016 20:00:57 +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: <20161207190057.GA58950@vlakno.cz> In-Reply-To: <D9C54972-8D21-4D55-A707-4FFC2BDCD9FE@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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" : "=3Dr"(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 ca=
se.
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, (out=
s 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 co=
unter
> // 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/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=3D/usr/obj/powerpc64vtsc_clang_altbinutils_k=
ernel/powerpc.powerpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ -O=
2 -pipe -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KER=
NEL_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_cla=
ng_altbinutils_kernel/powerpc.powerpc64/usr/src/sys/GENERIC64vtsc-NODBG -m=
no-altivec -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredun=
dant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpoin=
ter-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__f=
reebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unkn=
own-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-erro=
r-parentheses-equality -Wno-e
> rror-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-va=
lue -msoft-float -std=3Diso9899: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: un=
recognized 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: unr=
ecognized 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: unr=
ecognized 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: un=
recognized 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/POWRPCARCPRM=
RM.pdf )
> >=20
> >> Whereas the classic architecture defines special-purpose registers (SP=
Rs) and
> >> two instructions to access them (Move to Special-Purpose Register (mts=
pr) and
> >> Move from Special-Purpose Register (mfspr)), Book E takes that model a=
nd defines
> >> optional device control registers (DCRs) and mtdcr and mfdcr instructi=
ons, and
> >> the EIS-defined performance monitor APU defines performance monitor re=
gisters
> >> (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 when
> > it is targeting FreeBSD for GENERIC64 based builds? (I include GENERIC64
> > 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 bugzilla
> > 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 abo=
ut
> > 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?20161207190057.GA58950>