[Simulavr-devel] Problem with gdb (not simulavr)

[Tak Auyeung]

The following is what I got when stepping through test_blink.asm in gdb-5.1:

--snip--
(gdb) load a.out
Loading section .text, size 0x3a lma 0x0
Start address 0x0, load size 58
Transfer rate: 464 bits in <1 sec, 29 bytes/write.
(gdb) symbol-file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...done.
(gdb) stepi
0x0000001a      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x0000001c      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x0000001e      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x00000020      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x00000022      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x0000002a      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x0000002c      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x0000002e      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
(gdb) stepi
0x00000028      50      LOOP:   rjmp    LIGHTS          ; go into an 
infinite loop
--snip--

You can see that stepi works, but the debugger fails to show which line 
is to be executed next (always shows line 50) even though it seems to 
understand the current PC correctly.

I can tell from the simulavr output that the debugger tries to read 
locations 0x800001 and 0x800002 after each 's' command. I think the 
debugger thinks the step ends with an exception, and the address of the 
instruction causing the exception (the next opcode) is on top of the 
stack. Since the stack is not used in this program, it has an address of 
0x0000, which is flagged as 0x800000.

In addition, when I tried to disassemble the program (location 0 to 8), 
the debugger tries to read back 0x800000 to 0x800007. It appears gdb 
gets confused about whether the code space has the flag or the data 
space has the flag.

I'll try to track this one down tomorrow. Happy new year!

--Tak