Date: Wed, 21 Oct 2020 18:09:56 -0700 From: Mark Millard <marklmi@yahoo.com> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: FYI: -x assembler-with-cpp -m32 use during buildkernel vs. gcc9 based cross-builds, at least for targeting aarch64 via use of some armv6 notation; more Message-ID: <4252FFCA-21C4-4C42-B3D4-8C213031D689@yahoo.com> References: <4252FFCA-21C4-4C42-B3D4-8C213031D689.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I've not tried to build via a gcc* toochain in a long time so I decided =
to try
again, picking aarch64 (tailored to -mcpu=3Dcortext-a72 targeting in my =
context)
as a way to learn the status. (I did not expect it to finish, even with =
some
effort to adjust simple things.)
After taking care of some source code notational issues that the attempt
ran into, it ran into the following . . .
aarch64-unknown-freebsd13.0-gcc9: error: unrecognized command line =
option '-m32'
. . .
_ERROR_CMD=3D'/usr/local/bin/aarch64-unknown-freebsd13.0-gcc9 =
-mcpu=3Dcortex-a72 =
--sysroot=3D/usr/obj/cortexA72_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.=
aarch64/tmp -B/usr/local/aarch64-unknown-freebsd13.0/bin/ -x =
assembler-with-cpp -m32 -shared -nostdinc -nostdlib =
-Wl,-T/usr/src/sys/compat/cloudabi/cloudabi_vdso.lds =
/usr/src/sys/contrib/cloudabi/cloudabi_vdso_armv6_on_64bit.S -o =
cloudabi32_vdso.o;
In other words, it appears that the build environment for buildkernel =
has not
stuck to command line handling that is handled by both the llvm*/clang* =
toochain(s)
and the gcc* toolchain(s): It expects aarch64 targeting to accept
-x assembler-with-cpp -m32 in order to assemble armv6 notation ( such as =
for
cloudabi_vdso_armv6_on_64bit.S ). gcc* does not support that way of =
specifying
such behavior.
The context is head -r365932 .
For reference: the prior notational differences that I worked
around to see "what would be next" were (up to E-mail
whitespace variations):
# svnlite diff /usr/src/sys/arm64/arm64/locore.S
Index: /usr/src/sys/arm64/arm64/locore.S
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/arm64/arm64/locore.S (revision 365932)
+++ /usr/src/sys/arm64/arm64/locore.S (working copy)
@@ -296,10 +296,10 @@
cmp x2, #(ID_AA64PFR0_GIC_CPUIF_EN >> ID_AA64PFR0_GIC_SHIFT)
b.ne 2f
=20
- mrs x2, icc_sre_el2
+ mrs x2, s3_4_c12_c9_5 /* icc_sre_el2 */
orr x2, x2, #ICC_SRE_EL2_EN /* Enable access from insecure =
EL1 */
orr x2, x2, #ICC_SRE_EL2_SRE /* Enable system =
registers */
- msr icc_sre_el2, x2
+ msr s3_4_c12_c9_5, x2 /* icc_sre_el2 */
2:
=20
/* Set the address to return to our return address */
(I've not tested if llvm/clang allows the alternate notation used
above yet.)
machine/db_machdep.h has a && that appears to me to be wrong:
should instead be || . Look for the "/* <<<=3D=3D=3D was: && */"
comment in the below.
#define is_load_instr(ins) ((((ins) & 0x3b000000u) =3D=3D =
0x18000000u) || /* literal */ \
(((ins) & 0x3f400000u) =3D=3D =
0x08400000u) || /* exclusive */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x28400000u) || /* no-allocate pair */ \
((((ins) & 0x3b200c00u) =3D=3D =
0x38000400u) && \
(((ins) & 0x3be00c00u) !=3D =
0x38000400u) && \
(((ins) & 0xffe00c00u) !=3D =
0x3c800400u)) || /* immediate post-indexed */ \
((((ins) & 0x3b200c00u) =3D=3D =
0x38000c00u) && \
(((ins) & 0x3be00c00u) !=3D =
0x38000c00u) && \
(((ins) & 0xffe00c00u) !=3D =
0x3c800c00u)) || /* immediate pre-indexed */ \
((((ins) & 0x3b200c00u) =3D=3D =
0x38200800u) && \
(((ins) & 0x3be00c00u) !=3D =
0x38200800u) && \
(((ins) & 0xffe00c00u) !=3D =
0x3ca00c80u)) || /* register offset */ \
((((ins) & 0x3b200c00u) =3D=3D =
0x38000800u) && \
(((ins) & 0x3be00c00u) !=3D =
0x38000800u)) || /* unprivileged */ \
((((ins) & 0x3b200c00u) =3D=3D =
0x38000000u) && \
(((ins) & 0x3be00c00u) !=3D =
0x38000000u) && \
(((ins) & 0xffe00c00u) !=3D =
0x3c800000u)) || /* unscaled immediate */ \
((((ins) & 0x3b000000u) =3D=3D =
0x39000000u) && \
(((ins) & 0x3bc00000u) !=3D =
0x39000000u) && \
(((ins) & 0xffc00000u) !=3D =
0x3d800000u)) || /* <<<=3D=3D=3D was: && */ /* unsigned immediate */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x28400000u) || /* pair (offset) */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x28c00000u) || /* pair (post-indexed) */ \
I will note that the above lists (((ins) & 0x3bc00000u) =3D=3D =
0x28400000u)
twice, once for "no-allocate pair" and once for "pair (offset)", such =
that
the 2nd use can not change the overall expression true vs. false status.
But the following has that same issue in a simpler context:
#define is_store_instr(ins) ((((ins) & 0x3f400000u) =3D=3D =
0x08000000u) || /* exclusive */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x28000000u) || /* no-allocate pair */ \
((((ins) & 0x3be00c00u) =3D=3D =
0x38000400u) || \
(((ins) & 0xffe00c00u) =3D=3D =
0x3c800400u)) || /* immediate post-indexed */ \
((((ins) & 0x3be00c00u) =3D=3D =
0x38000c00u) || \
(((ins) & 0xffe00c00u) =3D=3D =
0x3c800c00u)) || /* immediate pre-indexed */ \
((((ins) & 0x3be00c00u) =3D=3D =
0x38200800u) || \
(((ins) & 0xffe00c00u) =3D=3D =
0x3ca00800u)) || /* register offset */ \
(((ins) & 0x3be00c00u) =3D=3D =
0x38000800u) || /* unprivileged */ \
((((ins) & 0x3be00c00u) =3D=3D =
0x38000000u) || \
(((ins) & 0xffe00c00u) =3D=3D =
0x3c800000u)) || /* unscaled immediate */ \
((((ins) & 0x3bc00000u) =3D=3D =
0x39000000u) || \
(((ins) & 0xffc00000u) =3D=3D =
0x3d800000u)) || /* unsigned immediate */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x28000000u) || /* pair (offset) */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x28800000u) || /* pair (post-indexed) */ \
(((ins) & 0x3bc00000u) =3D=3D =
0x29800000u)) /* pair (pre-indexed) */
So the redundancy does not seem surprising but just happens to be
textually just-after the && vs. || issue.
The && vs. || was noticed via gcc complaining about the lack of explicit
()'s to be explicit about && vs. || binding power in interpreting the
expression as it was (&& use).
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4252FFCA-21C4-4C42-B3D4-8C213031D689>