Hi Florian, > > > Unfortunately gdb also produces the same illegal instruction so I have not > > > been able to get much debug so far, any hints or clues as to what could be > > > wrong? > > > > No clue, but would you be able to get a core dump of a failing program? > > This would indicate what instruction has caused an issue and where, and > > then we can take it from there. > > Looks like GDB is not too happy with the core file I obtained, see below. Is > this a known issue with gdb-12.1? gdb-11.x was not faring any better > unfortunately. The core dump is attached (hope it makes it to the mailing > list). Sigh. Back in 2017 I fixed numerous issues with MIPS core file handling in GDB, which was then well-tested, and I haven't looked at it since. So it must be a regression, either in GDB or in the producer (Linux kernel). I can reproduce it and I'll see if I can debug this. I may ask you for the corresponding binary and shared libraries at one point. NB I note that the core file is ELF32 and does not have the EF_MIPS_ABI2 flag set in its file header, so it looks like an o32 core file to me. Since your subject mentions n32/n64, can you please check what kind of binary your `iperf3' is (e.g. `file iperf3', `readelf -h iperf3', etc.)? Maciej
