Bugzilla – Bug 1214736
powerpc64-suse-linux-gcc fails to build SLE11 kernel
Last modified: 2023-08-30 08:57:26 UTC
For some reason the LE gcc decides to instruct the assembler to assemble POWER7 instructions which the BE one does not: - # rs6000/powerpc options: -mcpu=power4 -mtune=cell -msdata=none + # rs6000/powerpc options: --with-cpu=power7 -mcpu=power4 -mtune=cell -msdata=none This results in unrecognized 'dssall' produced by inline assembly, and 'ldbrx', 'stdbrx' which are generated by gcc itself also fail to assemble.
Created attachment 869075 [details] BE gcc preprocessled file
Created attachment 869076 [details] BE gcc assembly
Created attachment 869077 [details] LE gcc preprocessed file
Created attachment 869078 [details] LE gcc assembly
powerpc64-suse-linux-gcc -mbig-endian -m64 -Wp,-MD,security/apparmor/.policy_unpack.o.d -nostdinc -isystem /usr/lib64/gcc/powerpc64-suse-linux/4.8/include -I/home/michal/kernel/arch/powerpc/include -Iarch/powerpc/include/generated -Iinclude -I/home/michal/kernel/include -include include/generated/autoconf.h -I/home/michal/kernel/security/apparmor -Isecurity/apparmor -D__KERNEL__ -I/home/michal/kernel/arch/powerpc -Iarch/powerpc -DHAVE_AS_ATHIGH=1 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -msoft-float -pipe -I/home/michal/kernel/arch/powerpc -Iarch/powerpc -mminimal-toc -mtraceback=no -mcall-aixdesc -mabi=elfv1 -mno-pointers-to-nested-functions -mcpu=power4 -mtune=cell -mno-altivec -mno-spe -mspe=no -funit-at-a-time -fno-dwarf2-cfi-asm -mno-string -Wa,-mpower7 -Wa,-maltivec -Wa,-mvsx -Wframe-larger-than=2048 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -fno-inline-functions-called-once -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(policy_unpack)" -D"KBUILD_MODNAME=KBUILD_STR(apparmor)" -c -o security/apparmor/.tmp_policy_unpack.o /home/michal/kernel/security/apparmor/policy_unpack.c {standard input}: Assembler messages: {standard input}:2623: Error: unrecognized opcode: `ldbrx' make[2]: *** [/home/michal/kernel/scripts/Makefile.build:334: security/apparmor/policy_unpack.o] Error 1 make[1]: *** [/home/michal/kernel/Makefile:1549: security/apparmor/policy_unpack.o] Error 2 make: *** [Makefile:144: sub-make] Error 2
GCC is configured to produce power7+ (depending on the SLE version you use) when targeting ppc64 because well, we decided so. powerpc64-suse-linux-gcc is a BE (cross?) compiler, I'm not sure a LE cross can produce big-endian code but ppc64le is at least power7 and there's no way to configure the default target differently for the different endianess I think. So why not simply specify the architecture you want to target? Please specify exactly what the "LE gcc" and the "BE gcc" are.
BE gcc powerpc64-suse-linux-gcc LE gcc powerpc64le-suse-linux-gcc If gcc thinks it's not building for power7 then it should not generate instructions that are only available on power7. Don't really care how it resolves so long as gcc can assemble the code it produces.
(In reply to Michal Suchanek from comment #7) > BE gcc powerpc64-suse-linux-gcc > LE gcc powerpc64le-suse-linux-gcc But what versions from which repository? You reported against Leap 15.4 so that means gcc7? LE should default to power8 there but 64bit BE defaults to power4. > If gcc thinks it's not building for power7 then it should not generate > instructions that are only available on power7. > > Don't really care how it resolves so long as gcc can assemble the code it > produces. It's still not clear to me what you report as bug? GCC doesn't assemble anything, it's the (cross) GNU as that does. GCC usually emits some .machine directive, but whether it does and how its named and how it behaves can differ for targets.
gcc 4.8 from Kernel:tools. They are rebuild of devel:gcc because the ones from devel:gcc are not usable.