https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121432
Bug ID: 121432
Summary: GCC 15.1.0 has a regression on Microblaze due to
commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b
Product: gcc
Version: 15.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: thomas.petazz...@free-electrons.com
Target Milestone: ---
As one of the maintainers of Buildroot (https://buildroot.org/), I regularly
test GCC on multiple architectures. We do have configurations building from
source a GCC cross-compiler, a Linux kernel and minimal Linux user-space for
many architectures.
And our configuration for the Microblaze architecture, which was working well
with GCC 14.x started failing with GCC 15.x, everything else being unchanged.
The GCC 14.x Microblaze setup would boot fine all the way to user-space, with
the final logs looking like this:
===========================================
Freeing unused kernel image (initmem) memory: 2008K
This architecture does not have kernel memory protection.
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
[... and more user-space logs ...]
===========================================
However, the exact same configuration built with GCC 15.x would hang after:
===========================================
Freeing unused kernel image (initmem) memory: 2004K
This architecture does not have kernel memory protection.
Run /init as init process
with arguments:
/init
with environment:
HOME=/
TERM=linux
===========================================
We bisected the issue at commit 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b. If we
build our toolchain with GCC at the commit just *before*
3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b, the generated system boots fine. If
we build our toolchain with GCC at commit
3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b, the generated system hangs at boot as
shown above.
We tried reverting 3b9b8d6cfdf59337f4b7ce10ce92a98044b2657b on top of GCC 15.x
but that leads to conflicts that are not trivial to resolve.
We looked into it a little bit more, and while the hang occurs when the kernel
transitions to user-space, the code generation issue is affecting the kernel.
Indeed:
* A kernel compiled with GCC 14.x with user-space compiled with GCC 15.x works
fine
* A kernel compiled with GCC 15.x with user-space compiled with GCC 14.x does
not work
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.
