[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] avr-gdb and simulavr memory addressing
From: |
manders1 |
Subject: |
Re: [avr-gcc-list] avr-gdb and simulavr memory addressing |
Date: |
Wed, 2 Jul 2003 13:45:08 -0400 |
> Date: Wed, 2 Jul 2003 09:31:24 -0700 (PDT)
> From: "Theodore A. Roth" <address@hidden>
> To: address@hidden
> cc: AVR GCC List <address@hidden>
> Subject: Re: [avr-gcc-list] avr-gdb and simulavr memory addressing
>
> On Wed, 2 Jul 2003 address@hidden wrote:
>
> > I tried to port some code that was running properly under
> > AVR Studio 3.55 and also on an AT90S8535. I got it to
> > assemble correctly using avr-as but when I was trying to
> > run it in the simulavr (avr-sim) I ran into a few error
> > messages that don't make any sense. They seem to be
> > coming from simulavr as a result of avr-gdb requesting
> > data from memory locations that are out of bounds but it
> > isn't clear why avr-gdb is requesting this data. These
> > error messages come out during execution of lines 22-25.
> >
> > Another thing I don't understand is the exact address
> > used for SRAM. Avr-gdb says it loads the .data section
> > at 0x18 right after the .text section. However when I
> > print the address of the first .data byte (var1) using
> > "print &var1" I get 0x800060. The real address though
> > seems to be 0x60 as expected if I dump the memory with
> > "x/xb 0x60". Is this normal?
>
> Gdb doesn't know anything about Harvard Arch targets and can only
> handle a single linear address space. Because of that we need to
> translate the sram space addresses by 0x800000 so that the flash and
> sram spaces don't overlap.
I figured as much. I convinced myself that the
simulavr was getting data from the correct memory
locations by printing out register values and
variable values.
> Consider this:
>
> (gdb) c
> Continuing.
>
> Breakpoint 1, main () at src/tst.c:38
> 38 volatile uint32_t sum = 1;
> (gdb) p &sum
> $1 = (volatile uint32_t *) 0x8010fc
> (gdb) x/4xb 0x8010fc
> 0x8010fc: 0x00 0x00 0x00 0x00
> (gdb) x/4xb 0x10fc
> 0x10fc: 0xff 0xff 0xff 0xff
>
> The first 'x' command reads sram, the second reads flash. Now,
> stepping over the initializer:
>
> (gdb) n
> 40 while (sum)
> (gdb) x/4xb 0x8010fc
> 0x8010fc: 0x01 0x00 0x00 0x00
> (gdb) x/4xb 0x10fc
> 0x10fc: 0xff 0xff 0xff 0xff
>
> Clear as mud, right? ;-)
>
> >
> >
> > 1 .file "mark.s"
> > 2 .arch avr2
> > 3
> > 4 tmp = 16
> > 5 SPL = 0x3D
> > 6 SPH = 0x3E
> > 7 ZL = 30
> > 8 ZH = 31
> > 9 RAMEND = 0x25F
> > 10
> > 11 .data
> > 12 0000 00 var1: .byte 0
> > 13 0001 00 var2: .byte 0
> > 14 .text
> > 15
> > 16 start:
> > 17 0000 02E0 ldi tmp, hi8 (RAMEND)
> > 18 0002 0EBF out SPH, tmp
> > 19 0004 0FE5 ldi tmp, lo8 (RAMEND)
> > 20 0006 0DBF out SPL, tmp
> > 21
> > 22 0008 00E0 ldi tmp, pm_hi8 (var1)
> > 23 000a F02F mov ZH, tmp
> > 24 000c 00E0 ldi tmp, pm_lo8 (var1)
> > 25 000e E02F mov ZL, tmp
> > 26 0010 01D0 rcall ini
> > 27 loop:
> > 28 0012 FFCF rjmp loop
> > 29
> > 30 ini:
> > 31 0014 00E0 ldi tmp, 0
> > 32 0016 0895 ret
> >
> > ~/AVR> avr-gdb mark
> > GNU gdb 5.3
>
> Just ran your program through the latest cvs gdb (6.0-branch):
>
> address@hidden:~/dev/test/foo$ avr-gdb mark.elf
> GNU gdb 2003-06-20-cvs
> Copyright 2003 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=avr"...
> (gdb) target remote :1212
> Remote debugging using :1212
> start () at mark.s:17
> 17 ldi tmp, hi8 (RAMEND)
> Current language: auto; currently asm
> (gdb) load
> Loading section .text, size 0x18 lma 0x0
> Loading section .data, size 0x2 lma 0x18
> Start address 0x0, load size 26
> Transfer rate: 208 bits in <1 sec, 13 bytes/write.
> (gdb) si
> start () at mark.s:18
> 18 out SPH, tmp
> (gdb)
> start () at mark.s:19
> 19 ldi tmp, lo8 (RAMEND)
> (gdb)
> start () at mark.s:20
> 20 out SPL, tmp
> (gdb)
> start () at mark.s:22
> 22 ldi tmp, pm_hi8 (var1)
> (gdb)
> start () at mark.s:23
> 23 mov ZH, tmp
> (gdb)
> start () at mark.s:24
> 24 ldi tmp, pm_lo8 (var1)
> (gdb)
> start () at mark.s:25
> 25 mov ZL, tmp
> (gdb)
> start () at mark.s:26
> 26 rcall ini
> (gdb)
> ini () at mark.s:31
> 31 ldi tmp, 0
> (gdb)
> 32 ret
> (gdb)
> loop () at mark.s:28
> 28 rjmp loop
> (gdb)
> 28 rjmp loop
> (gdb) quit
>
> > ~/AVR> avr-sim -g -d at90s8515
> >
> > Simulating a at90s8515 device.
> >
> > MESSAGE: file decoder.c: line 3352: generating opcode lookup_table
> > Waiting on port 1212 for gdb client to connect...
> > Connection opened by host 0.0.0.0, port 1439.
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0260
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0261
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0260
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0261
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0260
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0261
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0260
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0261
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0260
> > WARNING: file memory.c: line 148: **** Attempt to read invalid addr: 0x0261
>
> and used latest simulavr from cvs:
>
> address@hidden:~$ simulavr -g -d at90s8515
>
> Simulating a at90s8515 device.
>
> MESSAGE: file ../../src/decoder.c: line 3517: generating opcode
> lookup_table
> Waiting on port 1212 for gdb client to connect...
> Connection opened by host 0.0.0.0, port 51750.
> Waiting on port 1212 for gdb client to connect...
> Connection opened by host 0.0.0.0, port 51759.
> Waiting on port 1212 for gdb client to connect...
> address@hidden:~$ simulavr --version
>
> simulavr version 0.1.1.20030701
> Copyright 2001, 2002, 2003 Theodore A. Roth.
>
> simulavr is free software, covered by the GNU General Public License,
> and you are welcome to change it and/or distribute copies of it under
> the conditions of the GNU General Public License.
>
> address@hidden:~$
>
> No warnings that I can see. I used to see those warnings and think the
> problem is fixed in the latest gdb. The problem was gdb not knowing
> how to find the end of the stack frame chain and getting it's copying
> of the SP wrong.
>
> BTW: Where did you get avr-sim and what version is it? I've never
> released simulavr under that name.
I got simulavr-0.1.1.tar.gz from savannah and renamed the
executable to avr-sim so all of my AVR programs began with
the prefix "avr-". Sorry for the confusion.
> Also, gdb-5.3 has a few bugs with respect to avr that may cause it to
> crash. I'd suggest trying this:
>
>
> ftp://sources.redhat.com/pub/gdb/snapshots/branch/gdb+dejagnu-5.3.90_20030702.tar.bz2
>
> or what ever is the latest.
>
> Ted Roth
I downloaded that gdb file and it works as you describe,
no warnings at all.
Thanks for the help.
I have another question, more on software development.
If I were to make changes to simulavr, either minor
changes or major additions, what do I have to do to
get those changes put back into the release if you
found that the changes might appeal to others? I have
two main ideas, enhance existing functionality
where I need it, mainly TWI right now, and longer term
to make a symbolic debugger (assembly only at first
since I'n not using C) that integrates with simulavr.
I know you said in your documentation that you separated
display from the simulation on purpose but I believe
that there is a lot to be said for a more integrated
environment, similar to AVR Studio but without Windows.
I think this can be done without changing the simulavr
code but wrapping it in a user interface. I'm thinking
Linux console not X because I have limited hardware
resources.
I know I also risk the criticism that I'm re-inventing
the wheel since gdb exists so have mercy on me. Gdb is
primitive from the command line and running graphical
debuggers in X isn't an option for low-end hardare. So
a nice ncurses symbolic debugger for AVR seems like a
reasonable tool.
What do you think? Anyone ever tried to do this?
--
mark anderson
address@hidden