[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #50 from Waldemar Brodkorb --- Hi Neal, same issue with this kernel. I tried to bisect the problem and it seems it has something todo with time64 conversion after 4.19 release. I wrote a mail to numato but did not get any response, yet. best regards Waldemar
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #49 from Neal Frager --- (In reply to Neal Frager from comment #43) > Unfortunately, when I switch from > > this config: > https://gitlab.com/buildroot.org/buildroot/-/blob/master/board/qemu/ > microblazeel-mmu/linux.config > > to this config: > https://github.com/numato/samplecode/blob/master/FPGA/MimasA7Mini/ > MimasA7MiniLinux-BSP/mimasa7mini_defconfig > > The boot does not even start with the qemu. > > output/host/bin/qemu-system-microblazeel -M petalogix-s3adsp1800 -kernel > output/images/linux.bin -serial stdio > VNC server running on 127.0.0.1:5900 > > > But I am still thinking the most likely issue is a Linux config option that > enables something which is not covered by Gopi's patch. Hopefully we can > figure out how to duplicate the failure with the qemu, so that Gopi can > easily work on it. > > Otherwise, can your bitstream run on an Artix-7 AC701 board? > https://www.amd.com/en/products/adaptive-socs-and-fpgas/evaluation-boards/ek- > a7-ac701-g.html I figured out what the issue was. If I use your defconfig: https://github.com/numato/samplecode/blob/master/FPGA/MimasA7Mini/MimasA7MiniLinux-BSP/mimasa7mini_defconfig And remove the following config: CONFIG_KERNEL_BASE_ADDR=0x8000 Then I can boot as shown below using your defconfig. The qemu is expecting a base address of 0x9000 instead of 0x8000, which was the reason I could not boot with your config previously. This means that the qemu is not able to duplicate the issue and real hardware is indeed needed. output/host/bin/qemu-system-microblazeel -M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio VNC server running on 127.0.0.1:5900 random: crng init done Ramdisk addr 0x, FDT at 0x9098e8dc Linux version 6.18.18 (nealf@xirengwts09) (microblazeel-buildroot-linux-gnu-gcc.br_real (Buildroot 2026.02-292-gc897438742-dirty) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #16 Tue Apr 21 15:33:14 IST 2026 setup_memory: min_low_pfn: 0x9 setup_memory: max_low_pfn: 0x98000 setup_memory: max_pfn: 0x98000 Zone ranges: DMA [mem 0x9000-0x97ff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x9000-0x97ff] Initmem setup node 0 [mem 0x9000-0x97ff] OF: reserved mem: Reserved memory: No reserved-memory node in the DT setup_cpuinfo: initialising setup_cpuinfo: No PVR support. Using static CPU info from FDT ERROR: Microblaze BARREL, MSR, PCMP or DIV-different for kernel and DTS ERROR: Microblaze HW_MUL-different for kernel and DTS wt_msr_noirq pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Kernel command line: console=ttyUL0 printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) Built 1 zonelists, mobility grouping on. Total pages: 32768 mem auto-init: stack:all(zero), heap alloc:off, heap free:off SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 irq-xilinx: /plb/interrupt-controller@8180: num_irq=4, edge=0xa ERROR: CPU CCF input clock not found /plb/timer@83c0: irq=1 ERROR: timer CCF input clock not found ERROR: Using CPU clock frequency clocksource: xilinx_clocksource: mask: 0x max_cycles: 0x, max_idle_ns: 30580167144 ns xilinx_timer_shutdown xilinx_timer_set_periodic sched_clock: 32 bits at 63MHz, resolution 16ns, wraps every 34359738360ns Calibrating delay loop... 1718.68 BogoMIPS (lpj=8593408) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) BUG: rwlock cpu recursion on CPU#0, swapper/0/0, (ptrval) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.18 #16 NONE Kernel Stack: (ptrval): c000a860 c06ede24 (ptrval): c0002298 c057db78 c06f71d8 c0037bfc c06edf40 00800300 (ptrval): c0002260 c0037c28 c057da84 c057dbfc c1401280 0001 c10079e0 c006bfb4 (ptrval): c0596a40 c0596a80 c06f472c c06ee000 c057dd48 c00141f0 (ptrval): 61a2 c00141e0 c06edf40 c06edf40 00800300 c0014230 c06ee000 (ptrval): c101c2b4 c06f72ac c00149c0 c1002400 0dc0 0cc0 (ptrval): c00cb19c 0040 c1006d80 c06f4cf0 c014f05c (ptrval): c1018000 c1018000 00800300 c06edf40 c0573678 (ptrval): 0100 c0014e88 c1007980 (ptrval): c016f348 c1005300 c1015400 (ptrval): c0151108 c0573678 (ptrval): c05735c8 0005 c1006d90 c1005300 c01511a8 c1005300 0002 (ptrval): 00800300
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #48 from Neal Frager --- Hi Waldemar, As a test, could you try the latest Linux 6.12.60 release tag from the linux-xlnx tree? I am wondering if any of the commits that are not yet upstream might be a resolution for your system stall issue. Latest Xilinx release tag: https://github.com/Xilinx/linux-xlnx/releases/tag/xlnx_rebase_v6.12_LTS_merge_6.12.60 To use with Buildroot: BR2_LINUX_KERNEL_CUSTOM_TARBALL=y BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION="$(call github,Xilinx,linux-xlnx,xlnx_rebase_v6.12_LTS_merge_6.12.60)/xlnx_rebase_v6.12_LTS_merge_6.12.60.tar.gz" If this Linux kernel version works, we can try cherry picking the patch you need and upstreaming it. Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #47 from Waldemar Brodkorb --- Hi Neal, yes it is a second issue. But I think it is some Linux kernel bug introduced after 4.19.x. (the used kernel config is always the same). So this bug report is just to fix the gcc 15.x regression we should work on this. For me gopi's patch does not fix the issue on real hardware. best regards Waldemar
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #46 from Neal Frager --- Waldemar, Thank you for your test results. If I understand it correctly, there seems to be a second issue causing your system to stall when using a Linux kernel newer than Linux 4.19. Even when using gcc v13 or gcc v14, you get a system stall when using a Linux kernel newer than 4.19. gcc-14.3.0 5.15.201without I get a shell, system stalls after 10 seconds It seems to me that the system stall is a second issue which is probably more specific to your Linux kernel config. Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #45 from Waldemar Brodkorb --- Looks like Gopi's patch is breaking startup of init for me. I have done intensive testing with different combinations: CompilerLinux Patches Result gcc-15.2.0 6.12.81 without kernel panic gcc-15.2.0 6.12.81 GopiIllegal opcode exception in kernel mode. gcc-15.2.0 6.12.81 br-patchI get a shell, system stalls after 10 seconds gcc-15.2.0 6.6.122 br-patchI get a shell, system stalls after 10 seconds gcc-15.2.0 6.1.164 br-patchI get a shell, system stalls after 10 seconds gcc-15.2.0 5.15.201br-patchI get a shell, system stalls after 10 seconds gcc-15.2.0 5.4.292 br-patchI get a shell, system stalls after 10 seconds gcc-15.2.0 4.19.320br-patchworking stable gcc-14.3.0 6.12.81 without I get a shell, system stalls after 10 seconds gcc-14.3.0 6.12.81 GopiIllegal opcode exception in kernel mode. gcc-14.3.0 5.15.201without I get a shell, system stalls after 10 seconds gcc-13.4.0 6.12.81 GopiIllegal opcode exception in kernel mode. gcc-12.5.0 6.12.81 GopiIllegal opcode exception in kernel mode. It seems I have problems with the Linux Kernel newer than 4.19.320 and the stability after init is starting the system. But with Gopi's patch init never works.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #44 from Neal Frager --- Waldemar, Could I ask you to perform a regression check for us? Keeping Gopi's Linux patch applied, could you test using either gcc v14 or gcc v15 with the work around patch below? https://github.com/buildroot/buildroot/blob/master/package/gcc/15.2.0/0003-gcc-config-microblaze-fix-ira-for-GCC15.patch I want to be sure that Gopi's partial patch is not breaking anything that used to be working. It would be good if you could verify that gcc v14 and gcc v15 with the above patch work fine on your hardware when applying Gopi's patch. Thanks for your support on this! Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #43 from Neal Frager --- Unfortunately, when I switch from this config: https://gitlab.com/buildroot.org/buildroot/-/blob/master/board/qemu/microblazeel-mmu/linux.config to this config: https://github.com/numato/samplecode/blob/master/FPGA/MimasA7Mini/MimasA7MiniLinux-BSP/mimasa7mini_defconfig The boot does not even start with the qemu. output/host/bin/qemu-system-microblazeel -M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio VNC server running on 127.0.0.1:5900 But I am still thinking the most likely issue is a Linux config option that enables something which is not covered by Gopi's patch. Hopefully we can figure out how to duplicate the failure with the qemu, so that Gopi can easily work on it. Otherwise, can your bitstream run on an Artix-7 AC701 board? https://www.amd.com/en/products/adaptive-socs-and-fpgas/evaluation-boards/ek-a7-ac701-g.html
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #42 from Waldemar Brodkorb --- I use this one from Numato: https://github.com/numato/samplecode/blob/master/FPGA/MimasA7Mini/MimasA7MiniLinux-BSP/mimasa7mini_defconfig Now I get (switched from OpenADK to Buildroot as buildsystem): clk: Disabling unused clocks Mem-Info: active_anon:0 inactive_anon:0 isolated_anon:0 active_file:16 inactive_file:0 isolated_file:0 unevictable:635 dirty:0 writeback:0 slab_reclaimable:105 slab_unreclaimable:417 mapped:0 shmem:0 pagetables:1 sec_pagetables:0 bounce:0 kernel_misc_reclaimable:0 free:61132 free_pcp:514 free_cma:0 Node 0 active_anon:0kB inactive_anon:0kB active_file:64kB inactive_file:0kB unevictable:2540kB isolated(anon):0kB isolated(file):0kB mapped:0kB dirty:0kB writeback:0kB shmem:0kB kernel_stack:176kB pagetables:4kB sec_pagetables:0kB all_unreclaimable? no Balloon:0kB DMA free:244528kB boost:0kB min:2008kB low:2508kB high:3008kB reserved_highatomic:0KB free_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:64kB inactive_file:0kB unevictable:2540kB writepending:0kB zspages:0kB present:262144kB managed:252028kB mlocked:0kB bounce:0kB free_pcp:2056kB local_pcp:2056kB free_cma:0kB lowmem_reserve[]: 0 0 0 DMA: 4*4kB (ME) 4*8kB (UME) 2*16kB (M) 3*32kB (UM) 4*64kB (UME) 3*128kB (UME) 2*256kB (ME) 5*512kB (UME) 3*1024kB (ME) 2*2048kB (UM) 57*4096kB (M) = 244528kB 674 total pagecache pages 65536 pages RAM 0 pages HighMem/MovableOnly 2529 pages reserved Kernel panic - not syncing: broken padding ---[ end Kernel panic - not syncing: broken padding ]---
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #41 from Neal Frager --- (In reply to Waldemar Brodkorb from comment #40) > It seems not to be an issue with my locally created patch. > It works fine for me in Qemu but not on real hardware. > Do you have any real microblaze hardware you could verify it? > thanks > Waldemar Could you share your Linux config when you build for your hardware? I believe it is more likely a difference between your hardware Linux config and the config we are using with the qemu build. As Gopi mentions, he did not cover every possible case with his patch, so perhaps you have a Linux config option which exposes something that his patch does not account for. I believe this is the most likely reason. More likely than something working on the qemu, but failing on real hardware. Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #40 from Waldemar Brodkorb --- It seems not to be an issue with my locally created patch. It works fine for me in Qemu but not on real hardware. Do you have any real microblaze hardware you could verify it? thanks Waldemar
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #39 from Neal Frager --- Of course I am building with binutils 2.45.1 instead of 2.46, but I don't think that should matter for this issue.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #38 from Neal Frager --- Waldemar, I have converted Gopi's diff to a proper patch that can be applied directly to your buildroot build. Perhaps you missed something when converting the diff over to a usable patch? Could you please try the patch https://gcc.gnu.org/bugzilla/attachment.cgi?id=64051 with your Linux 6.18.18 build? Using the qemu, it solves the problem on my side. Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #37 from Neal Frager --- Created attachment 64051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64051&action=edit buildroot patch for Linux entry.S file
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #36 from Neal Frager --- (In reply to Waldemar Brodkorb from comment #34) > Hi, > > with this patch I still get following output on my Numato Mimas A7 Mini: > [3.503255] Run /init as init process > [3.506819] with arguments: > [3.509763] /init > [3.512005] with environment: > [3.515114] HOME=/ > [3.517706] TERM=linux > [3.530417] Illegal opcode exception in kernel mode. > [3.534357] Oops: opcode exception, sig: 7 > [3.538428] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.18-1 #2 NONE > [3.545239] Registers dump: mode=80821ED0 > [3.549380] r1=C0821ED0, r2=, r3=FFFE, r4=C0802980 > [3.555255] r5=CFDF3430, r6=0C5F, r7=C0849000, r8=C0848000 > [3.561130] r9=CFE108E0, r10=65A2, r11=0C60, r12=CFDE9338 > [3.567267] r13=, r14=C0821F68, r15=C00093A8, r16= > [3.573486] r17=C00093B4, r18=3F7B7000, r19=BFCBCAA4, r20=48008E3C > [3.579706] r21=, r22=4800, r23=48009070, r24=BFCBDF2C > [3.585927] r25=BFCBDF24, r26=BFCBDF38, r27=BFCBDDC0, r28=48009070 > [3.592148] r29=, r30=0001, r31=C082C000, rPC=C00093B4 > [3.598369] msr=46A2, ear=BFCBDF24, esr=BFCBDF38, fsr=BFCBDDC0 > [3.604963] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0007 > [3.612280] ---[ end Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0007 ]--- > > GCC 15.2.0, Binutils 2.46.0, Linux 6.18.18, uClibc-ng 1.0.57 or glibc 2.42. > An older Linux kernel built with Buildroot 2018.11 does boot fine, so I do > not think it is my bitstream, which is behaving wrong. What could be the > reason for this panic? I just updated the qemu_microblazeel_mmu_defconfig from Linux 6.18.7 to 6.18.18 and here is my boot log: output/host/bin/qemu-system-microblazeel -M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio VNC server running on 127.0.0.1:5900 random: crng init done Ramdisk addr 0x, FDT at 0x908a0f9c Linux version 6.18.18 (nealf@xirengwts09) (microblazeel-buildroot-linux-gnu-gcc.br_real (Buildroot 2026.02-292-gc897438742-dirty) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #2 Fri Mar 27 14:05:36 GMT 2026 setup_memory: min_low_pfn: 0x9 setup_memory: max_low_pfn: 0x98000 setup_memory: max_pfn: 0x98000 Zone ranges: DMA [mem 0x9000-0x97ff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x9000-0x97ff] Initmem setup node 0 [mem 0x9000-0x97ff] OF: reserved mem: Reserved memory: No reserved-memory node in the DT setup_cpuinfo: initialising setup_cpuinfo: No PVR support. Using static CPU info from FDT wt_msr pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Kernel command line: printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) Built 1 zonelists, mobility grouping on. Total pages: 32768 mem auto-init: stack:all(zero), heap alloc:off, heap free:off SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 irq-xilinx: /plb/interrupt-controller@8180: num_irq=4, edge=0xa ERROR: CPU CCF input clock not found /plb/timer@83c0: irq=1 ERROR: timer CCF input clock not found ERROR: Using CPU clock frequency clocksource: xilinx_clocksource: mask: 0x max_cycles: 0x, max_idle_ns: 30580167144 ns xilinx_timer_shutdown xilinx_timer_set_periodic sched_clock: 32 bits at 63MHz, resolution 16ns, wraps every 34359738360ns Console: colour dummy device 80x25 printk: legacy console [tty0] enabled Calibrating delay loop... 1709.05 BogoMIPS (lpj=3418112) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Memory: 120420K/131072K available (5164K kernel code, 511K rwdata, 928K rodata, 2155K init, 188K bss, 10324K reserved, 0K cma-reserved) devtmpfs: initialized clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns posixtimers hash table entries: 512 (order: 0, 2048 bytes, linear) futex hash table entries: 256 (4096 bytes on 1 NUMA nodes, total 4 KiB, linear). NET: Registered PF_NETLINK/PF_ROUTE protocol family DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered clocksource: Switched to clocksource xilinx_clocksource NET: Registered PF_INET protocol family IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) tcp_listen_portaddr_hash
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #35 from Neal Frager --- (In reply to Waldemar Brodkorb from comment #34) > Hi, > > with this patch I still get following output on my Numato Mimas A7 Mini: > [3.503255] Run /init as init process > [3.506819] with arguments: > [3.509763] /init > [3.512005] with environment: > [3.515114] HOME=/ > [3.517706] TERM=linux > [3.530417] Illegal opcode exception in kernel mode. > [3.534357] Oops: opcode exception, sig: 7 > [3.538428] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.18-1 #2 NONE > [3.545239] Registers dump: mode=80821ED0 > [3.549380] r1=C0821ED0, r2=, r3=FFFE, r4=C0802980 > [3.555255] r5=CFDF3430, r6=0C5F, r7=C0849000, r8=C0848000 > [3.561130] r9=CFE108E0, r10=65A2, r11=0C60, r12=CFDE9338 > [3.567267] r13=, r14=C0821F68, r15=C00093A8, r16= > [3.573486] r17=C00093B4, r18=3F7B7000, r19=BFCBCAA4, r20=48008E3C > [3.579706] r21=, r22=4800, r23=48009070, r24=BFCBDF2C > [3.585927] r25=BFCBDF24, r26=BFCBDF38, r27=BFCBDDC0, r28=48009070 > [3.592148] r29=, r30=0001, r31=C082C000, rPC=C00093B4 > [3.598369] msr=46A2, ear=BFCBDF24, esr=BFCBDF38, fsr=BFCBDDC0 > [3.604963] Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0007 > [3.612280] ---[ end Kernel panic - not syncing: Attempted to kill init! > exitcode=0x0007 ]--- > > GCC 15.2.0, Binutils 2.46.0, Linux 6.18.18, uClibc-ng 1.0.57 or glibc 2.42. > An older Linux kernel built with Buildroot 2018.11 does boot fine, so I do > not think it is my bitstream, which is behaving wrong. What could be the > reason for this panic? I just updated the qemu_microblazeel_mmu_defconfig from Linux 6.18.7 to 6.18.18 and here is my boot log: output/host/bin/qemu-system-microblazeel -M petalogix-s3adsp1800 -kernel output/images/linux.bin -serial stdio VNC server running on 127.0.0.1:5900 random: crng init done Ramdisk addr 0x, FDT at 0x908a0f9c Linux version 6.18.18 (nealf@xirengwts09) (microblazeel-buildroot-linux-gnu-gcc.br_real (Buildroot 2026.02-292-gc897438742-dirty) 15.2.0, GNU ld (GNU Binutils) 2.45.1) #2 Fri Mar 27 14:05:36 GMT 2026 setup_memory: min_low_pfn: 0x9 setup_memory: max_low_pfn: 0x98000 setup_memory: max_pfn: 0x98000 Zone ranges: DMA [mem 0x9000-0x97ff] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x9000-0x97ff] Initmem setup node 0 [mem 0x9000-0x97ff] OF: reserved mem: Reserved memory: No reserved-memory node in the DT setup_cpuinfo: initialising setup_cpuinfo: No PVR support. Using static CPU info from FDT wt_msr pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 pcpu-alloc: [0] 0 Kernel command line: printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear) Built 1 zonelists, mobility grouping on. Total pages: 32768 mem auto-init: stack:all(zero), heap alloc:off, heap free:off SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 irq-xilinx: /plb/interrupt-controller@8180: num_irq=4, edge=0xa ERROR: CPU CCF input clock not found /plb/timer@83c0: irq=1 ERROR: timer CCF input clock not found ERROR: Using CPU clock frequency clocksource: xilinx_clocksource: mask: 0x max_cycles: 0x, max_idle_ns: 30580167144 ns xilinx_timer_shutdown xilinx_timer_set_periodic sched_clock: 32 bits at 63MHz, resolution 16ns, wraps every 34359738360ns Console: colour dummy device 80x25 printk: legacy console [tty0] enabled Calibrating delay loop... 1709.05 BogoMIPS (lpj=3418112) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) Memory: 120420K/131072K available (5164K kernel code, 511K rwdata, 928K rodata, 2155K init, 188K bss, 10324K reserved, 0K cma-reserved) devtmpfs: initialized clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns posixtimers hash table entries: 512 (order: 0, 2048 bytes, linear) futex hash table entries: 256 (4096 bytes on 1 NUMA nodes, total 4 KiB, linear). NET: Registered PF_NETLINK/PF_ROUTE protocol family DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations pps_core: LinuxPPS API ver. 1 registered pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti PTP clock support registered clocksource: Switched to clocksource xilinx_clocksource NET: Registered PF_INET protocol family IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear) tcp_listen_portaddr_hash
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #34 from Waldemar Brodkorb --- Hi, with this patch I still get following output on my Numato Mimas A7 Mini: [3.503255] Run /init as init process [3.506819] with arguments: [3.509763] /init [3.512005] with environment: [3.515114] HOME=/ [3.517706] TERM=linux [3.530417] Illegal opcode exception in kernel mode. [3.534357] Oops: opcode exception, sig: 7 [3.538428] CPU: 0 UID: 0 PID: 1 Comm: init Not tainted 6.18.18-1 #2 NONE [3.545239] Registers dump: mode=80821ED0 [3.549380] r1=C0821ED0, r2=, r3=FFFE, r4=C0802980 [3.555255] r5=CFDF3430, r6=0C5F, r7=C0849000, r8=C0848000 [3.561130] r9=CFE108E0, r10=65A2, r11=0C60, r12=CFDE9338 [3.567267] r13=, r14=C0821F68, r15=C00093A8, r16= [3.573486] r17=C00093B4, r18=3F7B7000, r19=BFCBCAA4, r20=48008E3C [3.579706] r21=, r22=4800, r23=48009070, r24=BFCBDF2C [3.585927] r25=BFCBDF24, r26=BFCBDF38, r27=BFCBDDC0, r28=48009070 [3.592148] r29=, r30=0001, r31=C082C000, rPC=C00093B4 [3.598369] msr=46A2, ear=BFCBDF24, esr=BFCBDF38, fsr=BFCBDDC0 [3.604963] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007 [3.612280] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007 ]--- GCC 15.2.0, Binutils 2.46.0, Linux 6.18.18, uClibc-ng 1.0.57 or glibc 2.42. An older Linux kernel built with Buildroot 2018.11 does boot fine, so I do not think it is my bitstream, which is behaving wrong. What could be the reason for this panic?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #33 from Neal Frager --- Gopi, I have tested https://gcc.gnu.org/bugzilla/attachment.cgi?id=64034 and I confirm that this fixes the Linux boot issue. You have now convinced me that the issue is indeed within the Linux kernel entry.S and not the gcc v15 compiler. Will you be able to make a patch for the entry.S that we can upstream to the Linux kernel to fix this issue? How can we proceeed? Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #32 from Gopi Kumar Bulusu --- Created attachment 64034 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=64034&action=edit This patch adds necessary stack space for outgoing arguments for some system calls from entry.S; It is not a tested patch and is not a final fix. PR121432 seems to be a defect in Linux kernel - arch/microblaze/kernel/entry.S ; C functions are invoked with arguments without allocating stack space for register params (for potential register spills). As a result kernel built using buildroot; boot hangs at the point of starting init -. This patch adds necessary stack space for few C function calls from entry.S (not all). After this patch, the kernel boots all the way to login prompt and root login works. Simple commands like ps work and show normal output. It is not a complete fix as there are additional C function calls in entry.S that do not allocate space for outgoing args in the caller's stack frame. The patch is not tested beyond checking that the kernel boots. Run /init as init process with arguments: /init with environment: HOME=/ TERM=linux Saving 256 bits of creditable seed for next boot Starting syslogd: OK Starting klogd: OK Running sysctl: OK Starting network: udhcpc: started, v1.37.0 udhcpc: broadcasting discover udhcpc: broadcasting select for 10.0.2.15, server 10.0.2.2 udhcpc: lease of 10.0.2.15 obtained from 10.0.2.2, lease time 86400 deleting routers adding dns 10.0.2.3 OK Starting crond: OK Welcome to Buildroot buildroot login:
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #31 from Gopi Kumar Bulusu --- Just an update - this does look like a full fledged "mini port" of linux kernel for MicroBlaze with gcc 15 A few trouble spots have been identified to help with fixing primarily the file arch/microblaze/kernel/entry.S Some files that get impacted with gcc 15 include linux/fs/dpath.o linux/fs/ioctl.o linux/fs/open.o (and more under linux/kernel) Basically entry.S has code to call system calls where it appears that MicroBlaze ABI must be honored
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #30 from Gopi Kumar Bulusu --- With respect to irq.o Here is how a workaround checks out to be working using the following process 1. Build a working version of kernel (use gcc 14.x) kernel boots 2. Copy over the irq.o built using gcc 15 kernel hangs 3. Update irq.o with the workaround Kernel boots ok 4. Kernel built with gcc 15 and irq.o updated with fix/workaround kernel hangs. It appears that there are additional issues with kernel for arch/microblaze Here is the description of workaround: To ensure a function f() called from entry.S (or some other .S) without setting up args space works - use the following method * rename f() to say f_cabi() * Mark f_cabi() as inline ... noinline f_real () (If noinline does not work __attribute__((__noinline__)) may be used) * from f() call f_real() with necessary arguments Note: This workaround works with the default compiler flags (-O2) used for building the objects under arch/microblaze/kernel; however if optimizations are turned out the work around does not work.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #29 from Gopi Kumar Bulusu --- > > You can find the microblaze bare-metal software here: > https://github.com/Xilinx/embeddedsw/tree/master/lib/bsp/standalone/src/ > microblaze > The failure happens at the point of invoking init - a bare metal is unlikely to be useful for issues that surface at that point. Using a script to identify problem areas
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #28 from Neal Frager --- (In reply to Gopi Kumar Bulusu from comment #27) > It is a structured process of analysis > > check gcc/config/microblaze/microblaze.cc > > MicroBlaze stack frames look like: > >+---+ > | | > | arguments for called | > | subroutines | > | (optional) | > | | > +---+ > | Link register| >low FP,SP->| | >memory +---+ > > > Based on the above description, there is nothing wrong with compiler using > the caller's stack frame to save r5 > > In fact when one looks at the "regression" - the first reaction is that it > looks like a compiler defect, however upon analyzing the ABI, the "blame" > shifts to the Linux Kernel for MicroBlaze I see your reasoning, and it does make sense that the issue could be within the Linux kernel considering that is the only place where we have reproduced this failure so far. Since you understand microblaze assembly language better than I do, could I ask you to have a look at how the bare-metal interrupt handling is done? Since the bare-metal applications seem to be working correctly with gcc v15, perhaps comparing the bare-metal solution with Linux might be worthwhile? You can find the microblaze bare-metal software here: https://github.com/Xilinx/embeddedsw/tree/master/lib/bsp/standalone/src/microblaze Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #27 from Gopi Kumar Bulusu --- It is a structured process of analysis check gcc/config/microblaze/microblaze.cc MicroBlaze stack frames look like: +---+ | | | arguments for called | | subroutines | | (optional) | | | +---+ | Link register| low FP,SP->| | memory +---+ Based on the above description, there is nothing wrong with compiler using the caller's stack frame to save r5 In fact when one looks at the "regression" - the first reaction is that it looks like a compiler defect, however upon analyzing the ABI, the "blame" shifts to the Linux Kernel for MicroBlaze
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #26 from Neal Frager --- (In reply to Gopi Kumar Bulusu from comment #25) > > (In reply to Thomas Petazzoni from comment #11) > > So I've been able to narrow down the issue to arch/microblaze/kernel/irq.o. > > I can't say it's the only file impacted, but as soon as I have this object > > file from GCC 15.x in my build, it fails > > > > Tried independent fixes for irq.c (make do_IRQ call another do_IRQ_real > marked as noinline) and entry.S ( changes to allocate ARGS_SIZE on both > paths to do_IRQ call) before passing on control to do_IRQ > > Execution continues and fails with this message > > Run /init as init process > with arguments: > /init > with environment: > HOME=/ > TERM=linux > > Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b > ---[ end Kernel panic - not syncing: Attempted to kill init! > exitcode=0x000b ]--- > > Understandably - there appear to be other places in arch/microblaze/kernel > that need to be fixed as well (example signal.c:do_notify_resume) > > Any suggestions ? Are you absolutely sure that there is an issue in the assembly code used by the Linux kernel? This code has been working without problems for a few years now. Are you sure that simply implementing a proper microblaze_callee_save_cost function in gcc is not the right solution? Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #25 from Gopi Kumar Bulusu --- (In reply to Thomas Petazzoni from comment #11) > So I've been able to narrow down the issue to arch/microblaze/kernel/irq.o. > I can't say it's the only file impacted, but as soon as I have this object > file from GCC 15.x in my build, it fails > Tried independent fixes for irq.c (make do_IRQ call another do_IRQ_real marked as noinline) and entry.S ( changes to allocate ARGS_SIZE on both paths to do_IRQ call) before passing on control to do_IRQ Execution continues and fails with this message Run /init as init process with arguments: /init with environment: HOME=/ TERM=linux Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ]--- Understandably - there appear to be other places in arch/microblaze/kernel that need to be fixed as well (example signal.c:do_notify_resume) Any suggestions ?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #24 from Gopi Kumar Bulusu --- Yes already building with 15.2 Figured the patch was in and removed the patch and restarted the build. Once I get kernel to fail, planning a simpler fix (workaround ?) in irq.c out of respect for entry.S
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #23 from Neal Frager --- (In reply to Gopi Kumar Bulusu from comment #22) > OK, when a kernel is built using buildroot without that patch, it seems to > work fine. However kernel does not boot when the patch is applied. > > Needs more analysis. Stay tuned. When you test with buildroot, you need to do the following. 1. Remove the gcc 15.2.0 patch that buildroot is currently using to work around the problem: https://gitlab.com/buildroot.org/buildroot/-/blob/master/package/gcc/15.2.0/0003-gcc-config-microblaze-fix-ira-for-GCC15.patch 2. Add the following config to either configs/qemu_microblazeel_mmu_defconfig or configs/qemu_microblazebe_mmu_defconfig to use gcc 15.2.0 and not 14.3.0. The reported issue only appears when using gcc 15. BR2_GCC_VERSION_15_X=y After you have done this, you can modify the entry.S source file directly and keep rebuilding new Linux kernel images until you have a solution that works. Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #22 from Gopi Kumar Bulusu --- OK, when a kernel is built using buildroot without that patch, it seems to work fine. However kernel does not boot when the patch is applied. Needs more analysis. Stay tuned.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #21 from Gopi Kumar Bulusu --- Here is a patch outline (not yet built or tested); Note: 1) There can be other ways to fix the issue that can be explored (change do_IRQ function type) 2) There may be other places where there are similar issues ; This may not be a fix for every similar problem. arch/microblaze/kernel>diff entry.S.prev entry.S 732d731 < irq_call:rtbd r0, do_IRQ; 733a733,735 > irq_call:rtbd r0, do_IRQ; > addik r1, r1, -8; /* Allocate space for args and link register */ > addik r1, r1, 8; /* Free space for args and link register */ alma153~kernel>diff -U3 entry.S.prev entry.S --- entry.S.prev2026-03-18 13:24:16.380001878 +0530 +++ entry.S 2026-03-18 13:23:41.319001313 +0530 @@ -729,8 +729,10 @@ lwi CURRENT_TASK, r0, TOPHYS(PER_CPU(CURRENT_SAVE)); tovirt(r1,r1) addik r15, r0, irq_call; -irq_call:rtbd r0, do_IRQ; addik r5, r1, 0; +irq_call:rtbd r0, do_IRQ; + addik r1, r1, -8; /* Allocate space for args and link register */ + addik r1, r1, 8; /* Free space for args and link register */ /* MS: we are in virtual mode */
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #20 from Neal Frager --- (In reply to Gopi Kumar Bulusu from comment #19) > This does not look like a compiler defect. > > This becomes clear when look at the way stack is setup and used in the > interrupt handler defined in entry.S > > C_ENTRY(_interrupt): > > Here stack space is allocated for pt_regs structure > > addik r1, r1, -PT_SIZE; > SAVE_REGS > > However SAVE_REGS does not actually use the top 8 bytes of the stack; > > But then this instruction can be seen to access r1(4) > > swi r11, r1, PT_R1; > > After an rtbd to do_IRQ() > > do_IRQ() can be seen to access (what it sees as callers frame) where it > expects space to be allocated for inbound arguments > > + c: f8a10024swi r5, r1, 36 > > The value of r5 will be overwriting value of r11 stored in pt_regs > > It would be a simple fix in the arch/microblaze/kernel/entry.S > > This PR may be marked as INVALID Thank you for this analysis! Could you create a simple patch fix to the arch/microblaze/kernel/entry.S file, so we can apply it to the Linux kernel and verify this? Assuming you are correct, could you also upstream your patch to the Linux kernel? Best regards, Neal Frager AMD
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 Gopi Kumar Bulusu changed: What|Removed |Added CC||gopi at sankhya dot com --- Comment #19 from Gopi Kumar Bulusu --- This does not look like a compiler defect. This becomes clear when look at the way stack is setup and used in the interrupt handler defined in entry.S C_ENTRY(_interrupt): Here stack space is allocated for pt_regs structure addik r1, r1, -PT_SIZE; SAVE_REGS However SAVE_REGS does not actually use the top 8 bytes of the stack; But then this instruction can be seen to access r1(4) swi r11, r1, PT_R1; After an rtbd to do_IRQ() do_IRQ() can be seen to access (what it sees as callers frame) where it expects space to be allocated for inbound arguments + c: f8a10024swi r5, r1, 36 The value of r5 will be overwriting value of r11 stored in pt_regs It would be a simple fix in the arch/microblaze/kernel/entry.S This PR may be marked as INVALID
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #18 from Sam James --- (In reply to Neal Frager from comment #17) > Just checking. Is anyone actively working on creating a proper fix for this > issue? I'm not aware of anyone working on it. If anyone, it'll be the microblaze maintainer (Michael Eager) but we haven't heard off him much recently. Honestly, the microblaze port could really do with some more love from consumers of it. Not sure if you or some AMD colleagues can submit a patch?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #17 from Neal Frager --- Just checking. Is anyone actively working on creating a proper fix for this issue?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #16 from Thomas Petazzoni --- Created attachment 62129 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62129&action=edit irq.i.xz Here is the requested irq.i, built with the broken GCC 15.2. I had to compress it, otherwise it was larger than the 2 MiB limit.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #15 from Sam James --- (In reply to Romain Naour from comment #10) > This is probably not the correct fix... I hope it help. Indeed, it's a workaround, not a fix. It's an okay one to use for now though downstream if you need to.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 Richard Biener changed: What|Removed |Added Target Milestone|15.2|15.3 --- Comment #14 from Richard Biener --- GCC 15.2 is being released, retargeting bugs to 15.3.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #13 from Sam James --- Good work. I suspect pinskia is going to be right and it's a botched libcall impl (see PR103383, PR107459). Can you delete irq.o, run make V=1, and share the command line used to build irq.o? Then run that command you found again and append -save-temps, then upload irq.i here?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #12 from Thomas Petazzoni --- I can confirm: if I take all object files from GCC 14.x, and just arch/microblaze/kernel/irq.o from GCC 15.x, the issue occurs, where user-space applications don't work. I guess they are failing when they do a syscall.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #11 from Thomas Petazzoni --- So I've been able to narrow down the issue to arch/microblaze/kernel/irq.o. I can't say it's the only file impacted, but as soon as I have this object file from GCC 15.x in my build, it fails The assembly diff between the GCC 14.x file (before) and the GCC 15.x file (after) is as follows: --- before 2025-08-07 11:04:24.561779219 +0200 +++ after 2025-08-07 11:04:14.775803129 +0200 @@ -5,31 +5,30 @@ Disassembly of section .irqentry.text: : - 0: 3021ffdcaddik r1, r1, -36 - 4: fa61001cswi r19, r1, 28 - 8: f9e1swi r15, r1, 0 - c: fac10020swi r22, r1, 32 + 0: 3021ffe0addik r1, r1, -32 + 4: f9e1swi r15, r1, 0 + 8: fa61001cswi r19, r1, 28 + c: f8a10024swi r5, r1, 36 10: b000imm 0 - 14: eac0lwi r22, r0, 0 + 14: ea60lwi r19, r0, 0 18: b000imm 0 1c: f8a0swi r5, r0, 0 20: b000imm 0 24: b9f4brlid r15, 0 - 28: 1265addkr19, r5, r0 + 28: 8000or r0, r0, r0 2c: b000imm 0 30: e860lwi r3, r0, 0 34: 99fc1800brald r15, r3 - 38: 10b3addkr5, r19, r0 + 38: e8a10024lwi r5, r1, 36 3c: b000imm 0 40: b9f4brlid r15, 0 44: 8000or r0, r0, r0 48: e9e1lwi r15, r1, 0 4c: b000imm 0 - 50: fac0swi r22, r0, 0 + 50: fa60swi r19, r0, 0 54: ea61001clwi r19, r1, 28 - 58: eac10020lwi r22, r1, 32 - 5c: b60f0008rtsdr15, 8 - 60: 30210024addik r1, r1, 36 + 58: b60f0008rtsdr15, 8 + 5c: 30210020addik r1, r1, 32 Disassembly of section .init.text: So to me the code is identical to the exception of which registers are used... which makes sense since our problematic GCC commit is about register allocation if I understood correctly (I am not at all a compiler expert). The corresponding C code is pretty short: https://elixir.bootlin.com/linux/v6.16/source/arch/microblaze/kernel/irq.c
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432
Romain Naour changed:
What|Removed |Added
CC||romain.naour at gmail dot com
--- Comment #10 from Romain Naour ---
Hello,
Some architectures (aarch64 and x86) defines hooks for callee-save [1].
Just for testing, I added a new hook for callee-save on microblaze and
return 1 (like [2]) to restore the old behaviour prior to the commit [3].
gcc/config/microblaze/microblaze.cc:
/* Implement TARGET_CALLEE_SAVE_COST. */
static int
microblaze_callee_save_cost (spill_cost_type, unsigned int hard_regno,
machine_mode,
unsigned int, int mem_cost, const HARD_REG_SET &, bool)
{
return 1;
}
#undef TARGET_CALLEE_SAVE_COST
#define TARGET_CALLEE_SAVE_COST microblaze_callee_save_cost
With that the system boot correctly.
This is probably not the correct fix... I hope it help.
[1]
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b191e8bdecf881d11c1544c441e38f4c18392a15
[2]
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386.cc;h=3128973ba79cccfc6761f451dcb716b9558cc4da;hb=d3ff498c478acefce35de04402f99171b4f64a1a#l20606
[3]
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
Best regards,
Romain
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #9 from Sam James --- (In reply to Thomas Petazzoni from comment #8) > Thanks for the amazingly quick feedback! > > (In reply to Sam James from comment #3) > > * Compressed binaries of the kernel before and after the commit > > This is definitely doable. > > > * Take the build tree of the kernel with gcc-good, and gcc-bad (where it's > > one commit before and then the bad commit) and copy objects from the gcc-bad > > tree into the gcc-commit tree, re-running make repeatedly, until you find > > which the bad object is (if no LTO is involved, it has to be one object) > > But there are 915 object files in this kernel. This is going to take ages. > Do you have some suggestions? Use cmp (or diff) to get a list of differing objects, then you can bisect that list: copy the top half from bad -> good, does it work? if it works still, throw away that top half, and copy in the bottom half as a sanity check (should fail now). repeatedly halve & copy the list. It doesn't take long then as you're binary searching
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #8 from Thomas Petazzoni --- Thanks for the amazingly quick feedback! (In reply to Sam James from comment #3) > * Compressed binaries of the kernel before and after the commit This is definitely doable. > * Take the build tree of the kernel with gcc-good, and gcc-bad (where it's > one commit before and then the bad commit) and copy objects from the gcc-bad > tree into the gcc-commit tree, re-running make repeatedly, until you find > which the bad object is (if no LTO is involved, it has to be one object) But there are 915 object files in this kernel. This is going to take ages. Do you have some suggestions?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107459 --- Comment #7 from Andrew Pinski --- Even PR 107459.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103383 --- Comment #6 from Andrew Pinski --- Could be PR 103383.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #5 from Sam James --- (In reply to Sam James from comment #4) > (In reply to Andrew Pinski from comment #2) > > Does Microblaze still use reload? > > I think so ... Uses LRA since r14-383-gfaf8bea79b6256.
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #4 from Sam James --- (In reply to Andrew Pinski from comment #2) > Does Microblaze still use reload? I think so ...
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #3 from Sam James --- (In reply to Thomas Petazzoni from comment #0) > However, at this point we are a bit clueless on how to move forward with the > investigation. The issue is reproducible in Qemu, which we are using for > testing. Let us know what additional details would be useful to help > investigate this issue. A list: * Compressed binaries of the kernel before and after the commit * Take the build tree of the kernel with gcc-good, and gcc-bad (where it's one commit before and then the bad commit) and copy objects from the gcc-bad tree into the gcc-commit tree, re-running make repeatedly, until you find which the bad object is (if no LTO is involved, it has to be one object) * Once you have that object, we'll need preprocessed source corresponding to it (but we'll worry about that when you get there)
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 --- Comment #2 from Andrew Pinski --- Does Microblaze still use reload?
[Bug target/121432] [15/16 regression] GCC has a regression on Microblaze since r15-1619-g3b9b8d6cfdf593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432 Sam James changed: What|Removed |Added Summary|GCC 15.1.0 has a regression |[15/16 regression] GCC has |on Microblaze due to commit |a regression on Microblaze |g:3b9b8d6cfdf59337f4b7ce10c |since |e92a98044b2657b |r15-1619-g3b9b8d6cfdf593 CC||eager at eagercon dot com Target|Microblaze | Target Milestone|--- |15.2 Keywords||wrong-code --- Comment #1 from Sam James --- That commit means it was latent, unfortunately.
