qemu: uncaught target signal 4 (Illegal instruction) but gdb remote-debug exited normally

[Dong JianQiang]

I'm getting Illegal instruction (core dumped) when running the attached a.out_err binary in qemu, but when using Gdb to remote-debug the program, it exited normally. will appreciate if you can help look into this qemu issue.

readelf -h a.out_err
ELF Header:
  Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
  Class: ELF32
  Data: 2's complement, little endian
  Version: 1 (current)
  OS/ABI: UNIX - System V
  ABI Version: 0
  Type: EXEC (Executable file)
  Machine: ARM
  Version: 0x1
  Entry point address: 0x8220
  Start of program headers: 52 (bytes into file)
  Start of section headers: 54228 (bytes into file)
  Flags: 0x5000200, Version5 EABI, soft-float ABI
  Size of this header: 52 (bytes)
  Size of program headers: 32 (bytes)
  Number of program headers: 3
  Size of section headers: 40 (bytes)
  Number of section headers: 16
  Section header string table index: 15

qemu-arm version 4.0.0

[Peter Maydell (pmaydell)]

QEMU 4.0 is quite old now -- does this reproduce with a more recent QEMU?

[Dong JianQiang (johndong)]

yes, it reproduced on QEMU 5.0.0.

[Peter Maydell (pmaydell)]

For me, with current head-of-git QEMU, the program crashes with a SIGSEGV very early in execution, because:

0x00008260: e59f30f0 ldr r3, [pc, #0xf0]

loads 0 into r3, and then

0x00008270: e1a0d003 mov sp, r3

sets sp to 0, and then

0x000087b0: e92d4030 push {r4, r5, lr}

tries to write to addres 0, which causes a SEGV.

This happens whether using the gdbstub or not.

[Dong JianQiang (johndong)]

   0x00008260 <+64>: ldr r3, [pc, #240]
   0x00008264 <+68>: cmp r1, #0
=> 0x00008268 <+72>: beq 0x8270
   0x0000826c <+76>: mov r3, r1
   0x00008270 <+80>: mov sp, r3

(gdb) p/x $r1
$2 = 0xfffef690

But r1 is not zero when using Gdb remote-debug, so it will enter
   0x0000826c <+76>: mov r3, r1

QEMU 5.0.0.
GNU gdb (GDB; SUSE Linux Enterprise 12) 8.0.1

[Peter Maydell (pmaydell)]

Oh, your code is trying to use the SYS_HEAPINFO semihosting call to figure out where the stack and heap are. This is generally a bad idea if you're using QEMU user-mode emulation: you start with a perfectly good stack pointer and you should just use the usual Linux syscalls to allocate heap if you need it.

I have no idea where your code is getting r1 from -- it's too painful to try to reverse-engineer it from the binary. I can't repro any difference between with-gdb and without -- for me with current QEMU r1 is 0 whether running with the gdb stub or not.

[Thomas Huth (th-huth)]

The QEMU project is currently moving its bug tracking to another system.
For this we need to know which bugs are still valid and which could be
closed already. Thus we are setting the bug state to "Incomplete" now.

If the bug has already been fixed in the latest upstream version of QEMU,
then please close this ticket as "Fix released".

If it is not fixed yet and you think that this bug report here is still
valid, then you have two options:

1) If you already have an account on gitlab.com, please open a new ticket
for this problem in our new tracker here:

    https://gitlab.com/qemu-project/qemu/-/issues

and then close this ticket here on Launchpad (or let it expire auto-
matically after 60 days). Please mention the URL of this bug ticket on
Launchpad in the new ticket on GitLab.

2) If you don't have an account on gitlab.com and don't intend to get
one, but still would like to keep this ticket opened, then please switch
the state back to "New" or "Confirmed" within the next 60 days (other-
wise it will get closed as "Expired"). We will then eventually migrate
the ticket automatically to the new system (but you won't be the reporter
of the bug in the new system and thus you won't get notified on changes
anymore).

Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]