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

[Christof Frey]

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 ()
#3  0x020022e3 in ?? ()
#4  0x00ffffcc in ?? ()
#5  0x00000e18 in _init ()
#6  0x00ffffe0 in ?? ()
#7  0x00ffffe0 in ?? ()
#8  0xfffffffe in ?? ()
#9  0x00000000 in ?? ()
(gdb)

-----Original Message-----
From: Nathan Sidwell [mailto:nathan at codesourcery.com]
Sent: Friday, November 23, 2007 4:07 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:
> Hi all,
>
> I followed the getting started guide for 4.2-47 chapter 3.2 and
> implemented the fib.c accordingly to validate correct installation of
> the whole toolchain.
> The command line I used is:
> m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -o fib -g When
> trying to debug the application I get the following output in GDB:
>
> (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 0xe58 lma 0x0 Loading section .data, size
> 0x400 lma 0xe58 Start address 0x9ac, load size 4696 Transfer rate: 2
> KB/sec, 2348 bytes/write.
> (gdb) break main
> Breakpoint 1 at 0x60c: file fib.c, line 16.
> (gdb) continue
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb)
>
> I must admit that I had to change line 55 in file m5235evb.xml in
> order to get the initialization working:
> original:
>     <write-memory address="0x80000048" value="0x2308"/> changed to:
>     <write-memory address="0x40000048" value="0x2308"/> since
> 0x800000xx is not in the address space. I guess this was a bug (?)

Yes, thanks, that was a typo in the configuration file.

> A wonder why the application gets a zero divide trap ? (I think it is
> caused by write() function)

Are you able to generate a stack trace and determine the location of the trap?

nathan

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