[coldfire-gnu-discuss] Unexpected zero divide trap whilst running fib.c demo app

[Christof Frey]

late initialization from my image (from attached *zip - identical to yours):

0000098c <late_initialize>:
 98c:   223c 0000 0000  movel #0,%d1
 992:   4e7b 1801       movec %d1,%vbr
 996:   223c 8100 0000  movel #-2130706432,%d1
 99c:   4e7b 1002       movec %d1,%cacr
 9a0:   223c 4000 c040  movel #1073791040,%d1
 9a6:   4e7b 1004       movec %d1,%itt0
 9aa:   4e75            rts


stack values:

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

I solved the problem with the option -nostartfiles, so the command line that works is:

m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -nostartfiles -o fib -g

With above command line there is no change in the code of <late_initialize> but many other differences.


Christof
-----Original Message-----
From: Nathan Sidwell [mailto:nathan at codesourcery.com]
Sent: Monday, November 26, 2007 12:33 PM
To: Christof Frey
Cc: coldfire-gnu-discuss at codesourcery.com
Subject: Re: [coldfire-gnu-discuss] Unexpected zero divide trap whilst running fib.c demo app

Christof Frey wrote:
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb) backtrace
> #0  0x00000d32 in __cs3_isr_divide_by_zero ()
> #1  0x000009a0 in late_initialize ()
> #2  0x000008de in __do_global_ctors_aux ()

Thanks.  Here's the disassembly of late_initialize.

0000098c <late_initialize>:
  98c:   223c 0000 0000  movel #0,%d1
  992:   4e7b 1801       movec %d1,%vbr
  996:   223c 8100 0000  movel #-2130706432,%d1
  99c:   4e7b 1002       movec %d1,%cacr
  9a0:   223c 4000 c040  movel #1073791040,%d1
  9a6:   4e7b 1004       movec %d1,%itt0
  9aa:   4e75            rts

The reason you end up in __cs3_isr_divide_by_zero is because all the vectors point at the same routine (which stops).  The toolchain simply uses the first label that matches that address, which in this case is __cs3_isr_divide_by_zero.

Could you verify that your program image is the same as mine?
        m68k-elf-objdump -d fib
from the command line, or
        disassemble late_initialize
from gdb should do the trick.  If it's different, then just the late_initialize routine addresses are important.

Could you also find the stack values so we know exactly which trap you are experiencing?  You can do this with
        x/8x $sp
when gdb stops in the trap handler.

I've double checked and the 5235 part does have a cache, so writing to the cacr should be ok.  The value being written is 0x81000000, which should invalidate all the cache entries and enable caching.

nathan

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fib_dump.zip
Type: application/x-zip-compressed
Size: 8646 bytes
Desc: fib_dump.zip
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20071126/07398c82/attachment.bin>