Re: [avr-gcc-list] Puzzling Simulavr behaviour

[Theodore A. Roth]

On Thu, 28 Aug 2003, Erik Christiansen wrote:

> simulavr version 0.1.1.20030701
>
> Simulavr is really useful, and simulavr-disp so nicely supplements ddd.
> The following warnings, though, suggest that I don't quite have the hang
> of it yet.
>
> WARNING: file ../../src/memory.c: line 148: **** Attempt to read invalid 
> addr: 0x0460
> WARNING: file ../../src/memory.c: line 148: **** Attempt to read invalid 
> addr: 0x0461
>
> They appear, two per stepi, for each line in this listing from ddd's
> "Machine Code Window".
>
>     0x46 <_start>:          ldi     r16, 0x04       ; 4
>     0x48 <_start+2>:        out     0x3e, r16       ; 62
>     0x4a <_start+4>:        ldi     r16, 0x5F       ; 95
>     0x4c <_start+6>:        out     0x3d, r16       ; 61
>     0x4e <_start+8>:        eor     r20, r20
>     0x50 <_start+10>:       out     0x1a, r20       ; 26
>     0x52 <_start+12>:       ldi     r20, 0xFF       ; 255
>     0x54 <_start+14>:       out     0x1b, r20       ; 27
>     0x56 <_start+16>:       ldi     r16, 0x0A       ; 10
>     0x58 <_start+18>:       out     0x18, r1        ; 24
>     0x5a <_start+20>:       ldi     r16, 0xFB       ; 251
>     0x5c <_start+22>:       out     0x17, r1        ; 23
>
> Providing a -D option to simulavr:
>
> 0x000000 (0x000000) : 0x940c : JMP
> 0x000023 (0x000046) : 0xe004 : LDI
> 0x000024 (0x000048) : 0xbf0e : OUT
> 0x000025 (0x00004a) : 0xe50f : LDI
> 0x000026 (0x00004c) : 0xbf0d : OUT
> WARNING: file ../../src/memory.c: line 148: **** Attempt to read invalid
> addr: 0x0460
> WARNING: file ../../src/memory.c: line 148: **** Attempt to read invalid
> addr: 0x0461
> 0x000027 (0x00004e) : 0x2744 : EOR
> WARNING: file ../../src/memory.c: line 148: **** Attempt to read invalid
> addr: 0x0460
> WARNING: file ../../src/memory.c: line 148: **** Attempt to read invalid
> addr: 0x0461
>
> Throughout, the simulation works fine.
> Simulavr-disp shows all the right things happening in the registers,
> including the I/O ports.
>
> Trying to track the cause:
> In simulavr, the warning arises in mem_read() when VDevice* dev == NULL.
> This seems to suggest that the device is unknown, but the invocation is:
>
> simulavr -d atmega16 -g -P simulavr-disp &
>
> and the response is:
>
> Simulating a atmega16 device.
>
> Trying -d=atmega16 , as in the manpage synopsis, causes:
>
> WARNING: file ../../src/main.c: line 348: Device not supported:
> =atmega16
>
> and -datmega16 behaves the same as -d atmega16 .
>
> Has anyone encountered something alike?

What you are seeing is gdb accessing the the stack pointer after each
stepi (which is just gdb handling a breakpoint).

One of two things are happening:

- gdb is confused about where SP points to in memory (0x460 in your
  case).

- Your program has a bad SP value.

My guess is that you are using gdb-5.3 or older and the first case
holds. This should be fixed in the latest gdb snapshots. Grab the
latest gdb+dejagnu-5.3.90_* tarball from here:

  ftp://sources.redhat.com/pub/gdb/snapshots/branch/

There might be a first release candidate there later this weekend and
an official 6.0 release next weekend (unless they decided to push it
back again).

Ted Roth