gdb backtrace after SIGILL on Xscale (ARM)

gdb backtrace after SIGILL on Xscale (ARM)

[Shane Volpe]

I'm trying to perform a backtrace using gdb after a SIGILL event on an
Xscale (ARM) target device.  In order to simplify the issue I have
wrote a small program (http://en.wikipedia.org/wiki/SIGILL) whose only
purpose is to cause a SIGINT.

The code is:
int main()
{
    unsigned char insn[4] = { 0xff, 0xff, 0xff, 0xff };
    void (*function)() = (void (*)()) insn;
    function();
}

I compiled it as follows:
gcc -o sigill sigill.c

I then run it on my host machine 'Linux, Arch: x86"

gdb /home/sigill
(gdb) run
Starting program: /home/sigill

Program received signal SIGILL, Illegal instruction.
0xbf81d400 in ?? ()
(gdb) bt
#0  0xbf81d400 in ?? ()
#1  0x08048363 in main ()


Every thing work as expected, I got a backtrace showing me the correct steps.

I then compiled the program for my target system "Linux, Arch: Xscale (ARM)"
I ran the app and got the following:

 /home/sigill
BFD: /lib/.debug/ld-2.5.so: warning: sh_link not set for section `.ARM.exidx'
BFD: /lib/.debug/libc-2.5.so: warning: sh_link not set for section `.ARM.exidx'

Program received signal SIGILL, Illegal instruction.
0xbea7fc44 in ?? ()
(gdb) bt
#0  0xbea7fc44 in ?? ()
(gdb)

There is NO real information provided in the backtrace, why is this,
what might I be doing wrong?

Regards,
Shane

Re: gdb backtrace after SIGILL on Xscale (ARM)

[Harald Schiöberg]

This sounds like an EABI vs. OABI issue. see this thread:

http://sourceware.org/ml/gdb/2008-01/msg00032.html

harald


Shane Volpe wrote:
> I'm trying to perform a backtrace using gdb after a SIGILL event on an
> Xscale (ARM) target device.  In order to simplify the issue I have
> wrote a small program (http://en.wikipedia.org/wiki/SIGILL) whose only
> purpose is to cause a SIGINT.
> 
> The code is:
> int main()
> {
>     unsigned char insn[4] = { 0xff, 0xff, 0xff, 0xff };
>     void (*function)() = (void (*)()) insn;
>     function();
> }
> 
> I compiled it as follows:
> gcc -o sigill sigill.c
> 
> I then run it on my host machine 'Linux, Arch: x86"
> 
> gdb /home/sigill
> (gdb) run
> Starting program: /home/sigill
> 
> Program received signal SIGILL, Illegal instruction.
> 0xbf81d400 in ?? ()
> (gdb) bt
> #0  0xbf81d400 in ?? ()
> #1  0x08048363 in main ()
> 
> 
> Every thing work as expected, I got a backtrace showing me the correct steps.
> 
> I then compiled the program for my target system "Linux, Arch: Xscale (ARM)"
> I ran the app and got the following:
> 
>  /home/sigill
> BFD: /lib/.debug/ld-2.5.so: warning: sh_link not set for section `.ARM.exidx'
> BFD: /lib/.debug/libc-2.5.so: warning: sh_link not set for section `.ARM.exidx'
> 
> Program received signal SIGILL, Illegal instruction.
> 0xbea7fc44 in ?? ()
> (gdb) bt
> #0  0xbea7fc44 in ?? ()
> (gdb)
> 
> There is NO real information provided in the backtrace, why is this,
> what might I be doing wrong?
> 
> Regards,
> Shane


-- 
Harald Schiöberg
Technische Universität Berlin | T-Laboratories | FG INET
www: http://www.net.t-labs.tu-berlin.de
Phone: +49-(0)30-8353-58476 | Fax: +49-(0)391 534 783 47

Re: gdb backtrace after SIGILL on Xscale (ARM)

[Shane Volpe]

Harald,
Thanks for the feedback but I'm not sure it is the same issue.  In the
thread you referenced
"http://sourceware.org/ml/gdb/2008-01/msg00032.html" it looks like a
SIGILL was happening after a breakpoint and there was valid gdb
backtrace data present.  What I'm seeing is there is NO backtrace data
available after a SIGILL, this makes it impossible to use gdb for
debugging the cause of a SIGILL in my application.  I think my problem
is more like that of the following thread:
"http://sourceware.org/ml/gdb/2007-03/msg00155.html"  In fact that
thread was started by a co-worker of mine, we were never able to get
it working and gave up on it but now I want to get to the bottom of
the issue and get gdb working for backtracing SIGILLs on an ARM EABI
GLIBC system.

Summery of my system:
gdb version: 6.8
glibc version: 2.5
ARCH: PXA270 (xscale)
Linux Version: 2.6.23 (Distro: OpenEmbedded)

Regards,
Shane