host-gcc: exclude -lgcc to fix -mx32 [qemu_]x86_64 regression

PR zephyrproject-rtos#9522 series ending with commit c2c9265 ("tests: cmsis: Disable
two cmsis portability tests on x86_64") added -mx32 support for the
x86_64 ARCH and qemu_x86_64. While this was implemented in
"compiler/gcc/target.cmake" as fall back from cross-compilation to the
host compiler, it worked with a direct ZEPHYR_TOOLCHAIN_VARIANT=host
too.

Later, -lgcc was added to "compiler/host-gcc/target.cmake" by PR zephyrproject-rtos#12674
to fix the -m32 x86 build. This broke the x86_64 build when using
ZEPHYR_TOOLCHAIN_VARIANT=host because even "multilib" packages usually
don't feature the -mx32 version of libgcc.

Fix this by excluding -lgcc in compiler/host-gcc/target.cmake just like
compiler/gcc/target.cmake always did for x86_64.

Signed-off-by: Marc Herbert <[email protected]>

cmake/compiler/gcc/target.cmake

@@ -17,6 +17,8 @@ find_program(CMAKE_NM         ${CROSS_COMPILE}nm      PATH ${TOOLCHAIN_HOME} NO_
 # x86_64 should pick up a proper cross compiler if one is provided,
 # but falling back to using the host toolchain is a very sane behavior
 # too.
+# As an alternative to this fall back try ZEPHYR_TOOLCHAIN_VARIANT=host
+# directly.
 if(CONFIG_X86_64)
   if(CMAKE_C_COMPILER STREQUAL CMAKE_C_COMPILER-NOTFOUND)
     find_program(CMAKE_C_COMPILER   gcc    )

cmake/compiler/host-gcc/target.cmake

@@ -9,10 +9,19 @@ find_program(CMAKE_RANLILB      ranlib )
 find_program(CMAKE_READELF      readelf)
 find_program(CMAKE_GDB          gdb    )
 
-set(CMAKE_ASM_FLAGS           -m32 )
-set(CMAKE_C_FLAGS             -m32 )
-set(CMAKE_CXX_FLAGS           -m32 )
-set(CMAKE_SHARED_LINKER_FLAGS -m32 ) # unused?
+# -march={pentium,lakemont,...} do not automagically imply -m32, so
+# adding it here.
+
+# There's only one 64bits ARCH (actually: -mx32). Let's exclude it to
+# avoid a confusing game of "who's last on the command line wins".
+# Maybe the -m32/-miamcu FLAGS should all be next to -march= in the
+# longer term?
+if(NOT CONFIG_X86_64)
+  set(CMAKE_ASM_FLAGS           -m32 )
+  set(CMAKE_C_FLAGS             -m32 )
+  set(CMAKE_CXX_FLAGS           -m32 )
+  set(CMAKE_SHARED_LINKER_FLAGS -m32 ) # unused?
+endif()
 
 if(CONFIG_CPLUSPLUS)
   set(cplusplus_compiler g++)
@@ -28,19 +37,25 @@ else()
 endif()
 find_program(CMAKE_CXX_COMPILER ${cplusplus_compiler}     CACHE INTERNAL " " FORCE)
 
-# This libgcc code is partially duplicated in compiler/*/target.cmake
-execute_process(
-  COMMAND ${CMAKE_C_COMPILER} ${CMAKE_C_FLAGS} --print-libgcc-file-name
-  OUTPUT_VARIABLE LIBGCC_FILE_NAME
-  OUTPUT_STRIP_TRAILING_WHITESPACE
-  )
-assert_exists(LIBGCC_FILE_NAME)
+# The x32 version of libgcc is usually not available (can't trust gcc
+# -mx32 --print-libgcc-file-name) so don't fail to build for something
+# that is currently not needed. See comments in compiler/gcc/target.cmake
+if (NOT CONFIG_X86_64)
+  # This libgcc code is partially duplicated in compiler/*/target.cmake
+  execute_process(
+    COMMAND ${CMAKE_C_COMPILER} ${CMAKE_C_FLAGS} --print-libgcc-file-name
+    OUTPUT_VARIABLE LIBGCC_FILE_NAME
+    OUTPUT_STRIP_TRAILING_WHITESPACE
+    )
+  assert_exists(LIBGCC_FILE_NAME)
 
 # While most x86_64 Linux distributions implement "multilib" and have
 # 32 bits libraries off the shelf, things like
 # "/usr/lib/gcc/x86_64-linux-gnu/7/IAMCU/libgcc.a" are unheard of.
-# So this does not support CONFIG_X86_IAMCU=y
-LIST(APPEND TOOLCHAIN_LIBS gcc)
+# So this fails CONFIG_X86_IAMCU=y with a "cannot find -lgcc" error which
+# is clearer than "undefined reference to __udivdi3, etc."
+  LIST(APPEND TOOLCHAIN_LIBS gcc)
+endif()
 
 # Load toolchain_cc-family macros
 # Significant overlap with freestanding gcc compiler so reuse it

cmake/usage/usage.cmake

@@ -9,6 +9,7 @@ set(arch_list
   riscv32
   posix
   x86
+  x86_64
   xtensa
   )