[fpc-devel] ARM Illegal instruction debugging howto

[Jonas Maebe]

On 01 Dec 2009, at 19:36, ik wrote:

> gdb ./hello
> GNU gdb (GDB) 7.0
> Copyright (C) 2009 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "arm-oe-linux-gnueabi".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /var/volatile/tmp/hello...done.
> (gdb) break 1
> Breakpoint 1 at 0x807c: file ../../../../../tmp/hello.pp, line 1.
> (gdb) break 4
> Note: breakpoint 1 also set at pc 0x807c.
> Breakpoint 2 at 0x807c: file ../../../../../tmp/hello.pp, line 4.
> (gdb) r
> Starting program: /var/volatile/tmp/hello
> 
> Program received signal SIGILL, Illegal instruction.
> 0x00008abc in SYSTEM_FPC_CPUCODEINIT ()
> (gdb) bt
> #0  0x00008abc in SYSTEM_FPC_CPUCODEINIT ()
> #1  0x0000fbbc in SYSTEM_init ()
> #2  0x0000b268 in fpc_initializeunits ()
> #3  0x0000807c in $main () at ../../../../../tmp/hello.pp:3
> (gdb) c
> Continuing.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0x0000f670 in SYSTEM_REENABLE_SIGNAL$LONGINT$$BOOLEAN ()
> #2  0x00000000 in ?? ()
> (gdb) c
> Continuing.
> 
> Program exited with code 0330.

This does not appear to correspond to what you previously said about strace, since strace normally also show signals. I would guess (but these are really just wild guesses)  that the problem is one or more of the following:
a) the sigprocmask system call on your device has a different interface than the one expected by the rtl, or its sigset has a different number of elements
b) the definition of the signal handler context in the rtl does not correspond to whatever the kernel on your device uses. You can compare the definitions in rtl/linux/arm/sighndh.inc with similar ones referred to from ucontext_t or a similar type in your C headers; it doesn't matter if those structs contain more fields *after* the ones defined in the Pascal include file, but if they use a different order or other fields are defined in between, then that is a problem.

I'm not really interested in digging further in this though (I have too many things on my plate as it is), so I hope that someone else can continue helping you to debug and fix your problem.


Jonas