Re: soft and hard float n32 and n64 binaries getting illegal instructions on Cobalt Qube2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 8 Aug 2023, Maciej W. Rozycki wrote:

> > 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.)?

 I tweaked the core file and set the EF_MIPS_ABI2 flag by hand.  This has 
let GDB proceed:

[...]
warning: File "/usr/lib/debug/.build-id" has no build-id, file skipped
Core was generated by `iperf3 -c 192.168.254.3'.
Program terminated with signal SIGILL, Illegal instruction.
#0  0x77eb3190 in ?? (
[...]

but this is a partial core file only and I have no corresponding binaries, 
so I can't tell more at this stage, i.e. what code there is at 0x77eb3190 
(the PC address is suspiciously high in the 32-bit address space BTW, is 
that a PIE run with address space randomisation?).

 Of course GDB shouldn't have hit an internal error with a broken core 
file anyway, it should complain and handle the situation gracefully.  But 
in any case it's an issue with the Linux kernel producing a core file in 
the wrong format.

 Is this the most recent Linux kernel version you have obtained this with?  
There used to be a bug (regression) in Linux with n32 core files, but I 
fixed it also in 2017, with commit 547da673173d ("MIPS: Fix an n32 core 
file generation regset support regression").  So if it has stopped working 
again, then it's a new regression.  Would you be able to bisect it?

  Maciej



[Index of Archives]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux