On 2022-01-25 19:04, Vagrant Cascadian wrote:
On 2022-01-25, Vagrant Cascadian wrote:
On 2022-01-15, Aurelien Jarno wrote:
On 2022-01-11 16:40, Vagrant Cascadian wrote:
On 2022-01-11, Lennart Sorensen wrote:
On Mon, Jan 10, 2022 at 05:10:04PM -0800, Vagrant Cascadian wrote:
Something in the toolchain recently changed which causes u-boot arch:all build to FTBFS... I suspect binutils, as building in "bookworm" still works fine where binutils hasn't yet migrated.
On arch:all builds the qemu-ppce500 target is cross-compiled.
Full log:
https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=all&ver=2...
The hopefully relevent lines from the build log:
...
{standard input}: Assembler messages: {standard input}:127: Error: unrecognized opcode: `tlbre' {standard input}:418: Error: unrecognized opcode: `tlbre' {standard input}:821: Error: unrecognized opcode: `msync' {standard input}:821: Error: unrecognized opcode: `tlbwe' {standard input}:884: Error: unrecognized opcode: `tlbsx' make[4]: *** [/<<PKGBUILDDIR>>/scripts/Makefile.build:253: arch/powerpc/cpu/mpc85xx/tlb.o] Error 1 make[3]: *** [/<<PKGBUILDDIR>>/Makefile:1810: arch/powerpc/cpu/mpc85xx] Error 2 make[3]: *** Waiting for unfinished jobs.... powerpc-linux-gnu-gcc -Wp,-MD,arch/powerpc/lib/.traps.o.d -nost
...
The binutils versions appear to be:
succeeding, bookworm 2.37-10.1 failing, sid 2.37.50.20220106-2
Yep, this is due to commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a on the binutils side [1], which changes the behavior of `.machine` directives to override, rather than augment, the base CPU. GCC is called with -Wa,-me500 to enable PowerPC e500 instructions on the assembler side, but as the default GCC machine is ppc, a `.set machine ppc` is emitted at the beginning of the assembly code.
One option would be to force the CPU to e500 on the GCC side, however support for it has been removed. The options is therefore to force the machine in the assembly code. This is what the attached patch does.
Somehow I missed that you had attached a patch! I will try to get this tested and uploaded to Debian soon...
Your patch fixed building qemu-ppce500, but now I think we have a potentially similar problem with qemu-riscv64 and qemu-riscv64_smode:
/<<PKGBUILDDIR>>/arch/riscv/cpu/cpu.c: Assembler messages: /<<PKGBUILDDIR>>/arch/riscv/cpu/cpu.c:94: Error: unrecognized opcode `csrs sstatus,a5' /<<PKGBUILDDIR>>/arch/riscv/cpu/cpu.c:95: Error: unrecognized opcode `csrw 0x003,0' make[4]: *** [/<<PKGBUILDDIR>>/scripts/Makefile.build:254: arch/riscv/cpu/cpu.o] Error 1 make[3]: *** [/<<PKGBUILDDIR>>/Makefile:1810: arch/riscv/cpu] Error 2 make[3]: Leaving directory '/<<PKGBUILDDIR>>/debian/build/qemu-riscv64_smode'
I guess this is due to: http://lists.infradead.org/pipermail/linux-riscv/2022-January/011728.html
Unfortunately as the change has been done in a not yet released binutils version, there is no way for the fix to have been done upstream yet.
Note that this also breaks at least linux and opensbi.