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

[Mark Millard]

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=cortext-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='/usr/local/bin/aarch64-unknown-freebsd13.0-gcc9 -mcpu=cortex-a72 --sysroot=/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
===================================================================
--- /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
 
-	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:
 
 	/* 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 "/* <<<=== was: && */"
comment in the below.

#define is_load_instr(ins)      ((((ins) & 0x3b000000u) == 0x18000000u) || /* literal */ \
                                 (((ins) & 0x3f400000u) == 0x08400000u) ||  /* exclusive */ \
                                 (((ins) & 0x3bc00000u) == 0x28400000u) || /* no-allocate pair */ \
                                 ((((ins) & 0x3b200c00u) == 0x38000400u) && \
                                  (((ins) & 0x3be00c00u) != 0x38000400u) && \
                                  (((ins) & 0xffe00c00u) != 0x3c800400u)) || /* immediate post-indexed */ \
                                 ((((ins) & 0x3b200c00u) == 0x38000c00u) && \
                                  (((ins) & 0x3be00c00u) != 0x38000c00u) && \
                                  (((ins) & 0xffe00c00u) != 0x3c800c00u)) || /* immediate pre-indexed */ \
                                 ((((ins) & 0x3b200c00u) == 0x38200800u) && \
                                  (((ins) & 0x3be00c00u) != 0x38200800u) && \
                                  (((ins) & 0xffe00c00u) != 0x3ca00c80u)) || /* register offset */ \
                                 ((((ins) & 0x3b200c00u) == 0x38000800u) && \
                                  (((ins) & 0x3be00c00u) != 0x38000800u)) || /* unprivileged */ \
                                 ((((ins) & 0x3b200c00u) == 0x38000000u) && \
                                  (((ins) & 0x3be00c00u) != 0x38000000u) && \
                                  (((ins) & 0xffe00c00u) != 0x3c800000u)) ||  /* unscaled immediate */ \
                                 ((((ins) & 0x3b000000u) == 0x39000000u) && \
                                  (((ins) & 0x3bc00000u) != 0x39000000u) && \
                                  (((ins) & 0xffc00000u) != 0x3d800000u)) ||  /* <<<=== was: && */ /* unsigned immediate */ \
                                 (((ins) & 0x3bc00000u) == 0x28400000u) || /* pair (offset) */ \
                                 (((ins) & 0x3bc00000u) == 0x28c00000u) || /* pair (post-indexed) */ \

I will note that the above lists (((ins) & 0x3bc00000u) == 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) == 0x08000000u) || /* exclusive */ \
                                 (((ins) & 0x3bc00000u) == 0x28000000u) || /* no-allocate pair */ \
                                 ((((ins) & 0x3be00c00u) == 0x38000400u) || \
                                  (((ins) & 0xffe00c00u) == 0x3c800400u)) || /* immediate post-indexed */ \
                                 ((((ins) & 0x3be00c00u) == 0x38000c00u) || \
                                  (((ins) & 0xffe00c00u) == 0x3c800c00u)) || /* immediate pre-indexed */ \
                                 ((((ins) & 0x3be00c00u) == 0x38200800u) || \
                                  (((ins) & 0xffe00c00u) == 0x3ca00800u)) || /* register offset */ \
                                 (((ins) & 0x3be00c00u) == 0x38000800u) ||  /* unprivileged */ \
                                 ((((ins) & 0x3be00c00u) == 0x38000000u) || \
                                  (((ins) & 0xffe00c00u) == 0x3c800000u)) ||  /* unscaled immediate */ \
                                 ((((ins) & 0x3bc00000u) == 0x39000000u) || \
                                  (((ins) & 0xffc00000u) == 0x3d800000u)) ||  /* unsigned immediate */ \
                                 (((ins) & 0x3bc00000u) == 0x28000000u) || /* pair (offset) */ \
                                 (((ins) & 0x3bc00000u) == 0x28800000u) || /* pair (post-indexed) */ \
                                 (((ins) & 0x3bc00000u) == 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).

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)