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

[Nathan Sidwell]

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