Date: Wed, 7 Dec 2016 16:11:48 -0800 From: Mark Millard <markmi@dsl-only.net> To: Roman Divacky <rdivacky@vlakno.cz> 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: <E1376C20-C1BD-418D-81C6-CDDE479342CA@dsl-only.net> In-Reply-To: <20161207190057.GA58950@vlakno.cz> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
>=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 =
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.
=3D=3D=3D
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:
>=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, =
(outs 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/powerpc.powerpc64/usr/src/=
sys/GENERIC64vtsc-NODBG/modules/usr/src/sys/modules/hwpmc/hwpmc_e500.o.met=
a
> CMD /usr/bin/clang -B /usr/local/powerpc64-freebsd/bin/ -target =
powerpc64-unknown-freebsd12.0 =
--sysroot=3D/usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerp=
c64/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/sr=
c/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__=3D__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=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: =
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: =
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 =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/POWRPCARCPRMRM.pd=
f )
>>=20
>>> 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.
>>=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 =
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=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?E1376C20-C1BD-418D-81C6-CDDE479342CA>