[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Problem with gdb (not simulavr)
From: |
Theodore A. Roth |
Subject: |
Re: [Simulavr-devel] Problem with gdb (not simulavr) |
Date: |
Tue, 1 Jan 2002 14:25:06 -0700 (MST) |
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
:)
- [Simulavr-devel] Problem with gdb (not simulavr), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr),
Theodore A. Roth <=
- Re: [Simulavr-devel] Problem with gdb (not simulavr), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Tak Auyeung, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/01
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), reinhard . jessich, 2002/01/02
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/02
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), reinhard . jessich, 2002/01/02
- [Simulavr-devel] Project Management (was Problem with gdb (not simulavr) (disassemble)), Tak Auyeung, 2002/01/02
- Re: [Simulavr-devel] Project Management (was Problem with gdb (not simulavr) (disassemble)), Theodore A. Roth, 2002/01/02
- Re: [Simulavr-devel] Problem with gdb (not simulavr) (disassemble), Theodore A. Roth, 2002/01/03