hw/sparc/sun4m: Use qdev GPIOs rather than qemu_allocate_irqs()
In the sun4m machine creation code, we currently use qemu_allocate_irqs() to set up the IRQ lines that act as the inbound IRQ lines to the CPUs. This results in a memory leak: Direct leak of 128 byte(s) in 1 object(s) allocated from: #0 0x5a23c1281ec3 in malloc (/home/pm215/qemu/build/sparc-san/qemu-system-sparc+0xdf1ec3) (BuildId: e6aa10be01feb5524656dd083997bc82b85e3e93) #1 0x79e8f78f0ac9 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62ac9) (BuildId: 116e142b9b52c8a4dfd403e759e71ab8f95d8bb3) #2 0x5a23c1a94e54 in qemu_extend_irqs /home/pm215/qemu/build/sparc-san/../../hw/core/irq.c:77:51 #3 0x5a23c1a39e03 in cpu_devinit /home/pm215/qemu/build/sparc-san/../../hw/sparc/sun4m.c:802:17 #4 0x5a23c1a39e03 in sun4m_hw_init /home/pm215/qemu/build/sparc-san/../../hw/sparc/sun4m.c:838:9 The leak is unimportant as it is a "once at startup" leak, but fixing it helps in getting a clean leak-sanitizer test run. Switch the sun4m code to handle CPU interrupt lines in the same way as the leon3 machine does: the machine init code uses qdev_init_gpio_in to create GPIO lines on the CPU objects. This is a little bit odd as ideally the CPU would do that itself, but for these 32-bit SPARC machines the machine and the CPU are very closely coupled already (the functions handling the IRQ lines modify data fields inside the CPU). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20260307112931.3322532-3-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>