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

[Theodore A. Roth]

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.

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.

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