SIGILL on using GDB, in ld-linux-armhf.so.3

[sneakernets]

Disclaimer: I'm using the latest firmware...

I am working on zdoom, a Doom source port. However, when I attach zdoom to GDB on the Raspberry Pi, I get this:

Program received signal SIGILL, Illegal instruction.
0xb6fe8acc in ?? () from /lib/ld-linux-armhf.so.3

bt produces nothing of worth.

This is interesting, in that the program "runs" fine otherwise, but not with gdb.

Compiler: gcc 4.6.3-14+rpi1
Linux: 3.18.3+

[popcornmix]

I believe this is normal (I've seen this when debugging xbmc for a couple of years).
I suspect the code is deliberately executing the illegal instruction with a signal handler enabled (e.g. to determine whether optional instructions are supported).
See:
http://stackoverflow.com/questions/15071625/gdb-ddd-program-received-signal-sigill

[sneakernets]

I actually checked for this too, but even when I use handle SIGILL pass nostop noprint, the program dies in gdb with the same error. I suppose I should have noted that in the first post.

This has been hair-pullingly frustrating to figure out on my own for the past two weeks, so I threw in the towel today and submitted it as an issue. 😁

[nbrachet]

I have experienced this issue too after a recent upgrade -- sadly I don't remember which one.

I traced this SIGILL down to a static initialization in my code. Still frustrating issue.

[popcornmix]

@nbrachet A firmware/kernel upgrade, or other packages?

[nbrachet]

@popcornmix I'm afraid both.

[nbrachet]

If that helps the problem occurs whether I build with g++-4.6 or g++-4.8.

[popcornmix]

If it was a firmware/kernel update that caused it, then downgrading should fix it. You can revert to an older version:
http://raspberrypi.stackexchange.com/questions/15917/restore-kernel-version/15919#15919

[sneakernets]

If it helps, this started to be an issue around mid-december 2014.

[nbrachet]

I've tracked down the firmware version in which this bug appeared: cad071a, and it present up to the latest 93cb9a4

[sneakernets]

Yeah, it looks like 3.18 firmware update still has some rough edges. Thanks for letting me know!

[popcornmix]

Unfortunately the kernel change was the 3.12 to 3.18 (so literally tens of thousands of commits...)
Can you determine the instruction generating the exception (e.g. with "disas")

[popcornmix]

One thing I've notice is 3.18 kernel reports:
Features : half thumb fastmult vfp edsp java tls

The older kernel reports:
Features : swp half thumb fastmult vfp edsp java tls

The (deprecated) swp feature was removed here:
58171bf

So if the instruction is a swp instruction this may be relevant.

[nbrachet]

Here's the disas:

(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: test

Program received signal SIGILL, Illegal instruction.
0xb6fe8acc in ?? () from /lib/ld-linux-armhf.so.3
(gdb) disas 0xb6fe8acc,0xb6fe8aff
Dump of assembler code from 0xb6fe8acc to 0xb6fe8aff:
=> 0xb6fe8acc:  ldr r3, [pc, #164]  ; 0xb6fe8b78
   0xb6fe8ad0:  cmp r1, #0
   0xb6fe8ad4:  push    {r4}        ; (str r4, [sp, #-4]!)
   0xb6fe8ad8:  add r3, pc, r3
   0xb6fe8adc:  mov r2, r0
   0xb6fe8ae0:  beq 0xb6fe8b5c
   0xb6fe8ae4:  mov r0, #76 ; 0x4c
   0xb6fe8ae8:  ldr r12, [pc, #140] ; 0xb6fe8b7c
   0xb6fe8aec:  mul r0, r0, r1
   0xb6fe8af0:  add r12, pc, r12
   0xb6fe8af4:  add r0, r0, #56 ; 0x38
   0xb6fe8af8:  add r0, r0, r12
   0xb6fe8afc:  adds    r12, r2, #0
End of assembler dump.

Expanding on this...:

(gdb) disas 0xb6fe8ac0,0xb6fe8aff
Dump of assembler code from 0xb6fe8ac0 to 0xb6fe8aff:
   0xb6fe8ac0:  andeq   r12, r0, r12, lsr r4
   0xb6fe8ac4:  andeq   r12, r0, r8, lsl r5
   0xb6fe8ac8 <_dl_debug_state+0>:  bx  lr
=> 0xb6fe8acc:  ldr r3, [pc, #164]  ; 0xb6fe8b78
   0xb6fe8ad0:  cmp r1, #0
   0xb6fe8ad4:  push    {r4}        ; (str r4, [sp, #-4]!)
   0xb6fe8ad8:  add r3, pc, r3
   0xb6fe8adc:  mov r2, r0
   0xb6fe8ae0:  beq 0xb6fe8b5c
   0xb6fe8ae4:  mov r0, #76 ; 0x4c
   0xb6fe8ae8:  ldr r12, [pc, #140] ; 0xb6fe8b7c
   0xb6fe8aec:  mul r0, r0, r1
   0xb6fe8af0:  add r12, pc, r12
   0xb6fe8af4:  add r0, r0, #56 ; 0x38
   0xb6fe8af8:  add r0, r0, r12
   0xb6fe8afc:  adds    r12, r2, #0
End of assembler dump.

[popcornmix]

Can you post the binary that does this? (e.g. to dropbox or google drive)

[nbrachet]

https://dl.dropboxusercontent.com/u/1020551/rtpraspivid

Offending code is:

    int traceroute(...)
    {
#ifndef __ARM_EABI__
        static const uint16_t pid = getpid();
#else
        // gdb (raspberrypi) trips with SIGILL!?!
        // see https://github.com/raspberrypi/linux/issues/766
               const uint16_t pid = getpid();
#endif
...

When pid is defined as a static (as it is in the executable I posted to dropbox) the executable SIGILL in gdb.

Note that the same problem happens if I replace the call to getpid() with a call to:

static uint16_t foo()
{
    return 1234;
}

But it does not happen if I replace the call to getpid() with a constant:

    static const uint16_t pid = 1234;

It does feel like a stack corruption... Could gdb be corrupting the stack somehow?