From: Segher Boessenkool <segher@kernel.crashing.org>
To: Jan-Benedict Glaw <jbglaw@lug-owl.de>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: Mass-building defconfigs: many fail with assembler errors
Date: Mon, 12 Dec 2022 18:26:13 -0600 [thread overview]
Message-ID: <20221213002613.GG25951@gate.crashing.org> (raw)
In-Reply-To: <20221212215117.aa7255t7qd6yefk4@lug-owl.de>
Hi!
On Mon, Dec 12, 2022 at 10:51:17PM +0100, Jan-Benedict Glaw wrote:
> Is anybody else routinely building current Binutils + GCC, to try to
> build all the Linux defconfigs?
I do regularly build kernels for powerpc-linux, powerpc64-linux,
powerpc64le-linux; ppc6xx_defconfig and ppc64_defconfig and
ppc64le_defconfig. Totally boring, but it frequently does not build.
Not as frequently as for the other Linux targets I build (32 total at
the moment).
> For PPC, a good number of those fail,
> and I probably don't understand PPC well enough to propose patches. Or
> did I pick wrongly targeted toolchains? Most of the time, my suspicion
> is that we're not giving the correct -m<cpu> flags in
> ./arch/powerpc/boot/? (My setup for doing test builds is fairly automated, I
> can easily throw in patches for testing.)
Many of those use a 32-bit toolchain with a 64-bit kernel, or they
require some e500 specific config but not getting it (or the other way
around).
> 64-bit.config
> ==> Why "-m32 -mcpu=powerpc"? Binutils/GCC are for --target=powerpc64-linux
Something in your config is forcing that.
> 85xx-64bit.config
> powerpc64-linux-gcc -Wp,-MMD,arch/powerpc/kernel/vdso/.gettimeofday-64.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m64 -Wl,-a64 -mabi=elfv1 -Wa,-me500 -Wa,-me500mc -mabi=elfv1 -mbig-endian -Wl,-soname=linux-vdso64.so.1 -D__VDSO64__ -s -c -o arch/powerpc/kernel/vdso/gettimeofday-64.o arch/powerpc/kernel/vdso/gettimeofday.S
e500mc is a 32-bit core. This cannot fly.
> 85xx-hw.config
> powerpc-linux-gcc -Wp,-MMD,arch/powerpc/kernel/.epapr_hcalls.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -D__KERNEL__ -I ./arch/powerpc -fmacro-prefix-map=./= -D__ASSEMBLY__ -fno-PIE -m32 -Wl,-a32 -mcpu=powerpc -mbig-endian -c -o arch/powerpc/kernel/epapr_hcalls.o arch/powerpc/kernel/epapr_hcalls.S
> arch/powerpc/kernel/epapr_hcalls.S: Assembler messages:
> arch/powerpc/kernel/epapr_hcalls.S:24: Error: unrecognized opcode: `wrteei'
wrteei is a BookE instruction (not a PowerPC instruction), and something
specifically asked for just PowerPC.
> powernv_defconfig
> cc1: all warnings being treated as errors
Self-inflicted wound. The warnings may reveal more, or they might show
something that GCC isn't as good at as you may want; all warnings have
false positives, that is why they are warnings and not errors.
> Compiler ICEs (during GIMPLE pass: ccp) in align.c:
>
> powerpc-linux-gcc -Wp,-MMD,arch/powerpc/kernel/.align.o.d -nostdinc -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/compiler-version.h -include ./include/linux/kconfig.h -include ./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc -fmacro-prefix-map=./= -Wall -Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration -Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11 -mbig-endian -m32 -msoft-float -pipe -ffixed-r2 -mmultiple -mno-readonly-in-sdata -mcpu=440 -mno-prefixed -mno-pcrel -mno-altivec -mno-vsx -mno-mma -fno-asynchronous-unwind-tables -mno-string -Wa,-m440 -mbig-endian -mstack-protector-guard=tls -mstack-protector-guard-reg=r2 -fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-overflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wframe-larger-than=1024 -fstack-protector-strong -Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer -ftrivial-auto-var-init=zero -fno-stack-clash-protection -Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=date-time -Werror=incompatible-pointer-types -Werror=designated-init -Wno-packed-not-aligned -g -mstack-protector-guard-offset=1080 -Werror -DKBUILD_MODFILE='"arch/powerpc/kernel/align"' -DKBUILD_BASENAME='"align"' -DKBUILD_MODNAME='"align"' -D__KBUILD_MODNAME=kmod_align -c -o arch/powerpc/kernel/align.o arch/powerpc/kernel/align.c
> during GIMPLE pass: ccp
> arch/powerpc/kernel/align.c: In function '__copy_inst_from_kernel_nofault':
> arch/powerpc/kernel/align.c:364:1: internal compiler error: in maybe_register_def, at tree-into-ssa.cc:1948
> 364 | }
> | ^
> 0x19d8886 internal_error(char const*, ...)
> ???:0
> 0x7bb4fe fancy_abort(char const*, int, char const*)
> ???:0
> 0x1791bfe dom_walker::walk(basic_block_def*)
> ???:0
> 0xe94ec0 update_ssa(unsigned int)
> ???:0
> 0x103d6b9 execute_update_addresses_taken()
> ???:0
> Please submit a full bug report, with preprocessed source (by using -freport-bug).
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.
> make[3]: *** [scripts/Makefile.build:250: arch/powerpc/kernel/align.o] Error 1
> make[2]: *** [scripts/Makefile.build:500: arch/powerpc/kernel] Error 2
> make[1]: *** [scripts/Makefile.build:500: arch/powerpc] Error 2
> make: *** [Makefile:1992: .] Error 2
>
> ==> Should probably open a PR for this.
Yes please!
Segher
next prev parent reply other threads:[~2022-12-13 0:27 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-12 21:51 Mass-building defconfigs: many fail with assembler errors Jan-Benedict Glaw
2022-12-13 0:26 ` Segher Boessenkool [this message]
2022-12-13 10:00 ` Jan-Benedict Glaw
2022-12-14 9:00 ` Jan-Benedict Glaw
2022-12-14 18:36 ` Jan-Benedict Glaw
2022-12-14 20:08 ` Segher Boessenkool
2022-12-15 8:47 ` Jan-Benedict Glaw
2022-12-13 3:49 ` Michael Ellerman
2022-12-13 8:41 ` Jan-Benedict Glaw
2022-12-13 12:23 ` Segher Boessenkool
2022-12-14 14:45 ` Jan-Benedict Glaw
2022-12-15 6:49 ` Christophe Leroy
2022-12-15 6:55 ` Christophe Leroy
2022-12-15 12:47 ` Michael Ellerman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221213002613.GG25951@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=jbglaw@lug-owl.de \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).