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

[Theodore A. Roth]

On Mon, 31 Dec 2001, Tak Auyeung wrote:

:)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.

Actually, I think gdb is just reading the stack pointer to try to figure 
out where it is as far as which frame the program is in.

:)
:)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.

Yeah, I've been battling this flash/sram space problem for a while now and 
I'm really not totally satisfied with my solution.

I think your problem above is due to the fact that gdb assumes it's 
working with a c program, thus it is always looking for a stack frame. 
Have you tried inline asm yet? I would expect that to work better. Also, 
I don't think it would hurt to init the stack even is a simple asm 
program.

When I told you that stepi was working for me, I forgot to note that I was 
just stepping instructions in a C program. In which case, gdb knows what 
it's doing. We'll need to work on the gdb patch so it knows what it's 
doing with a pure asm program.

Out of curiousity, have you tried native gdb on linux with an asm file? It 
might be enlightening to know it it can handle it.

:)
:)I'll try to track this one down tomorrow. Happy new year!
:)
:)--Tak
:)
:)
:)_______________________________________________
:)Simulavr-devel mailing list
:)address@hidden
:)http://mail.freesoftware.fsf.org/mailman/listinfo/simulavr-devel
:)