AVR - invalid address used when evaluating a variable

AVR - invalid address used when evaluating a variable

[Christo]

I am testing the debugging of AVR microcontrollers over debugWIRE with gdb. When evaluating the
value of a variable I noticed an incorrect value. On closer inspection I realized that gdb (8.1
compiled for AVR support) was reading flash memory, not SRAM.  When I evaluate the pointer to
the variable, gdb correctly reports the SRAM address. When reading the memory pointed to by this
pointer the correct value is returned.  This leads me to postulate that there is a
mistake/omission when gdb evaluates/prints a variable, resolve its address and then reads it
from flash rather than SRAM.

Below a short excerpt of debugging a simple program with a variable "i" which the compiler
located at address 0 in SRAM (which should be mapped to 0x800060, right after the io registers).
The program was compiled with Freepascal and debugged using a debugWIRE server.  I've called
"set debug remote 1" so that the rsp requests can be seen:

(gdb) print i
Sending packet: $m60,1#30...Ack
Packet received: 20
$7 = 32 ' '
(gdb) print &i
$8 = (Byte *) 0x800060 <TC_sPsBLINK_ss_I> Sending packet: $m800060,8#ff...Ack
Packet received: 020003B8F6777DD2
"\002"
(gdb) print *&i
Sending packet: $m800060,1#f8...Ack
Packet received: 02
$9 = 2 '\002'

Can anyone confirm this behaviour is indeed wrong/unexpected?

Re: AVR - invalid address used when evaluating a variable

[Simon Marchi]

On 2018-06-24 15:28, Christo wrote:
> I am testing the debugging of AVR microcontrollers over debugWIRE with
> gdb. When evaluating the
> value of a variable I noticed an incorrect value. On closer inspection
> I realized that gdb (8.1
> compiled for AVR support) was reading flash memory, not SRAM.  When I
> evaluate the pointer to
> the variable, gdb correctly reports the SRAM address. When reading the
> memory pointed to by this
> pointer the correct value is returned.  This leads me to postulate
> that there is a
> mistake/omission when gdb evaluates/prints a variable, resolve its
> address and then reads it
> from flash rather than SRAM.
> 
> Below a short excerpt of debugging a simple program with a variable
> "i" which the compiler
> located at address 0 in SRAM (which should be mapped to 0x800060,
> right after the io registers).
> The program was compiled with Freepascal and debugged using a
> debugWIRE server.  I've called
> "set debug remote 1" so that the rsp requests can be seen:
> 
> (gdb) print i
> Sending packet: $m60,1#30...Ack
> Packet received: 20
> $7 = 32 ' '
> (gdb) print &i
> $8 = (Byte *) 0x800060 <TC_sPsBLINK_ss_I> Sending packet: 
> $m800060,8#ff...Ack
> Packet received: 020003B8F6777DD2
> "\002"
> (gdb) print *&i
> Sending packet: $m800060,1#f8...Ack
> Packet received: 02
> $9 = 2 '\002'
> 
> Can anyone confirm this behaviour is indeed wrong/unexpected?

Hi Christo,

I am not proficient in Pascal.  Can you provide a test program, with all 
the command lines needed to reproduce?

Thanks,

Simon

Re: AVR - invalid address used when evaluating a variable

[Christo]

On Mon, 2018-06-25 at 21:02 -0400, Simon Marchi wrote:
> I am not proficient in Pascal.  Can you provide a test program, with all 
> the command lines needed to reproduce?

Hi Simon,

I'm using the development version of the Freepascal compiler to get the latest AVR support, so
bootstrapping a compiler to compile my test program may be too much hassle. Anyway, the example
code can be seen here: https://github.com/ccrause/fpc-avr/blob/master/src/examples/blink2/blink.
pp

I've also uploaded the compiled elf file in case you rather want to use this instead of
compiling it: https://github.com/ccrause/fpc-avr/blob/master/src/examples/blink2/bin/blink.elf

Anyway the compiler command line:
fpc/3.1.1/compiler/ppcrossavr -Tembedded -Pavr  -CpAVR25 -MObjFPC -Scghi -O4 -g -l -vewnhibq
-Filib/avr-embedded -Fu../../library -Fu. -FUlib/avr-embedded -FE. -oblink -Wpattiny45 -g -a
-XPavr- -al -Sm -Si -dF_CPU:=8000000

An example of a gdb session:
~/fpc/fpc-avr/src/examples/blink2 $ ~/gdb/gdb-8.1/gdb/avr-gdb-8.1.0-original 
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=avr".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) file bin/blink.elf 
Reading symbols from bin/blink.elf...done.
(gdb) target remote :2345
Remote debugging using :2345
0x00000000 in _START ()
(gdb) load
Loading section .text, size 0xb2 lma 0x0
Loading section .data, size 0x2 lma 0xb2
Start address 0x0, load size 180
Transfer rate: 505 bytes/sec, 25 bytes/write.
(gdb) set language pascal
(gdb) set debug remote 1
(gdb) print i
Sending packet: $m60,1#30...Ack
Packet received: 20
$1 = 32
(gdb) print @i
$2 = (^Sending packet: $m800060,8#ff...Ack
Packet received: 04000A00F6777DD2
Byte) 0x800060 #4
(gdb) print (@i)^
Sending packet: $m800060,1#f8...Ack
Packet received: 04
$3 = 4
(gdb)

From the above "print i" instruction one can see that gdb requests the memory content of address
0x60 which is in flash.  The "print @i" instruction should print the address of variable i,
which is correct, 0x800060.

I have also tested an equivalent C program compiled with avr-gcc, with gdb reading the correct
SRAM address for the value of i.  This makes me wonder if the symbol information generated by
Freepascal is correct?

Re: AVR - invalid address used when evaluating a variable

[Simon Marchi]

On 2018-06-26 16:32, Christo wrote:
> I have also tested an equivalent C program compiled with avr-gcc, with
> gdb reading the correct
> SRAM address for the value of i.  This makes me wonder if the symbol
> information generated by
> Freepascal is correct?

Looking quickly, that's what I see.  The variable "i" in your program is 
described as:

  <1><ca>: Abbrev Number: 3 (DW_TAG_variable)
     <cb>   DW_AT_name        : i
     <cd>   DW_AT_location    : 3 byte block: 3 60 0     (DW_OP_addr: 60)

In my C test program (compiled with -gdwarf-4), a global variable 
appears as:

  <1><5e0>: Abbrev Number: 11 (DW_TAG_variable)
     <5e1>   DW_AT_name        : foo
     ...
     <5ec>   DW_AT_location    : 5 byte block: 3 60 0 80 0       
(DW_OP_addr: 800060)

So I guess Freepascal should do the same, map data addresses at 
0x800000.

Simon

Re: AVR - invalid address used when evaluating a variable

[Christo]

On Tue, 2018-06-26 at 22:01 -0400, Simon Marchi wrote:
> On 2018-06-26 16:32, Christo wrote:
> > 
> > I have also tested an equivalent C program compiled with avr-gcc, with
> > gdb reading the correct
> > SRAM address for the value of i.  This makes me wonder if the symbol
> > information generated by
> > Freepascal is correct?
> Looking quickly, that's what I see.  The variable "i" in your program is 
> described as:
> 
>   <1><ca>: Abbrev Number: 3 (DW_TAG_variable)
>      <cb>   DW_AT_name        : i
>      <cd>   DW_AT_location    : 3 byte block: 3 60 0     (DW_OP_addr: 60)
> 
> In my C test program (compiled with -gdwarf-4), a global variable 
> appears as:
> 
>   <1><5e0>: Abbrev Number: 11 (DW_TAG_variable)
>      <5e1>   DW_AT_name        : foo
>      ...
>      <5ec>   DW_AT_location    : 5 byte block: 3 60 0 80 0       
> (DW_OP_addr: 800060)
> 
> So I guess Freepascal should do the same, map data addresses at 
> 0x800000.
> 
> Simon

Simon,

Thank you very much for your feedback.  I will take this issue to the Freepascal forum.

Best regards,
Christo