[coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo"

[Christof Frey]

is there any more support you can give on the subject or am I completely off track ?

(I had a similar behviour with a port of a larger application and thus wanted to start with this mickey - mouse example as outlined in the manuals - just to make sure I am not doing anything completely wrong)

Thank,
Christof

-----Original Message-----
From: Christof Frey
Sent: Tuesday, July 08, 2008 5:05 PM
To: 'Nathan Sidwell'
Cc: Mark Mitchell; coldfire-gnu-discuss at codesourcery.com
Subject: RE: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo"

Well, don't know whether the pgm arrived via an exception / trap there or GDB is lying. Stackframe looked odd to me as well (thus the stupid question where it starts...)

Code addresses:

<snip>
 .text          0x000008dc       0x16 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-_exit.o)
                0x000008dc                _exit
 *fill*         0x000008f2        0x2 00
 .text          0x000008f4       0x4c c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-write.o)
                0x000008f4                write
 .text          0x00000940      0x2b2 c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.3/../../../../m68k-elf/lib/m5208\libcs3hosted.a(hosted-gdb.o)
                0x00000940                __cs3_hosted_to_gdb_mode_t
                0x00000a2a                __cs3_hosted_from_gdb_stat
                0x00000a04                __cs3_hosted_to_gdb_lseek_flags
                0x00000a86                __cs3_hosted_from_gdb_timeval
                0x000009be                __cs3_hosted_to_gdb_open_flags
<snip>

Command line degugger:

..
(gdb) target remote|m68k-elf-sprite pe://ParallelPortCable m5235evb Remote debugging using |m68k-elf-sprite pe://ParallelPortCable m5235evb
m68k-elf-sprite: Opening P&E ParallelPortCable port 1 (LPT1 : Parallel Port 1 (A ddress $0378))
m68k-elf-sprite: Target reset
0x00000000 in __cs3_interrupt_vector_coldfire ()
(gdb) load
Loading section .text, size 0xdf4 lma 0x0 Loading section .eh_frame, size 0x4 lma 0xdf4 Loading section .rodata, size 0x68 lma 0xdf8 Loading section .data, size 0x400 lma 0xe60 Start address 0xcc4, load size 4704 Transfer rate: 2 KB/sec, 1176 bytes/write.
(gdb) break main
Breakpoint 1 at 0x608: file fib.c, line 16.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000d3a in __cs3_isr_divide_by_zero ()
(gdb) x/8xw $sp
0xffffb4:       0x000009a0      0x000008de      0x00000000      0x00ffffcc
0xffffc4:       0x00000e20      0x00ffffe0      0x00ffffe0      0xfffffffe
(gdb)

Code: (per example)

#include <unistd.h>
// this program uses the debugger for write() function static int Fib (unsigned n, unsigned a, unsigned b) {
        unsigned count;

        for (count = 0; count != b; count++) {
                write (1, ".", 1);
        }
        write (1, "\n", 1);
        if (n) {
                Fib (n-1, b, a + b);
        }
}

int main () {
        write (1, "Fibonacci\n", 10);
        Fib (9, 0, 1);
        return (0);
}

-----Original Message-----
From: Nathan Sidwell [mailto:nathan at codesourcery.com]
Sent: Tuesday, July 08, 2008 2:28 PM
To: Christof Frey
Cc: Mark Mitchell; coldfire-gnu-discuss at codesourcery.com
Subject: Re: [coldfire-gnu-discuss] zero divide trap when running Debug Sprite Example "Fibo"

Christof Frey wrote:
> According to CFPRM the stack frame is two long word:
> SSP -> 32 Bit control information
> SSP + 0x4 -> program counter
>
> So is the SSP pointing to 0xffffb4 below the frame of interest ?
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d3a in __cs3_isr_divide_by_zero ()
> (gdb) x/8xw $sp
> 0xffffb4:       0x000009a0      0x000008de      0x00000000      0x00ffffcc
> 0xffffc4:       0x00000e20      0x00ffffe0      0x00ffffe0      0xfffffffe

This is an odd stack frame, as there appears to be no sign of the control information.  The control information contains the original PSW and the exception information.  I'm wondering if you did arrive here via an exception.
The 0x9a0 and 0x8de look like they might be code addresses -- what is at those locations?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery