Re: [avr-gcc-list] avr-gdb and simulavr memory addressing

[manders1]

> 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