Discussion:
AVR debug info - bug 0033914
(too old to reply)
Christo
2018-06-30 19:51:13 UTC
Permalink
I'm trying to figure out how to fix bug 33914. This bug causes gdb to read variable addresses
from flash, not RAM.  Looking at the DWARF info, the address of a variable is written as a word,
while gdb expects a prefixed address ($800000 + address) to indicate a RAM address, so the size
of the address needs to be larger than 16 bits.  In dbgdwarf.pas it appears as if the size of
addresses are taken from pint/puint in globtype.pas and aitconst_ptr_unaligned in aasmtai.pas,
all of which are 16 bit sizes for AVR.

To fix the problem of storing the addresses of variables with RAM prefixes I've added a level of
indirection in dbgdwarf by adding the following declarations to remap the size of addresses for
AVR:

{$ifdef avr}
puint_d = cardinal;
pint_d = longint;
{$else avr}
puint_d = PUint;
pint_d = pint;
{$endif avr}

{$ifdef avr}
aitconst_ptr_unaligned_d = aitconst_32bit_unaligned;
{$else avr}
aitconst_ptr_unaligned_d = aitconst_ptr_unaligned;
{$endif avr}

Of course all instances pint/puint types and aitconst_ptr_unaligned constants are appended with
"_d" as part of this indirection.  A patch with this approach is attached to the bug report.

This appears to work correctly, but I'm not sure this is an elegant way of fixing the problem.
Any comments or hints on how to fix the issue more elegantly?
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Joost van der Sluis
2018-07-02 13:47:55 UTC
Permalink
Post by Christo
I'm trying to figure out how to fix bug 33914. This bug causes gdb to read variable addresses
from flash, not RAM.  Looking at the DWARF info, the address of a variable is written as a word,
while gdb expects a prefixed address ($800000 + address) to indicate a RAM address, so the size
of the address needs to be larger than 16 bits.  In dbgdwarf.pas it appears as if the size of
addresses are taken from pint/puint in globtype.pas and aitconst_ptr_unaligned in aasmtai.pas,
all of which are 16 bit sizes for AVR.
Of course all instances pint/puint types and aitconst_ptr_unaligned constants are appended with
"_d" as part of this indirection.  A patch with this approach is attached to the bug report.
This appears to work correctly, but I'm not sure this is an elegant way of fixing the problem.
Any comments or hints on how to fix the issue more elegantly?
Has been a long time ago, but my guess is that in some DWARF-header
there is an offset for the memory-locations. (The unit-info maybe?)

You should have a look at the Dwarf-specs. And maybe have a look at
other platforms, what is generated there.

Regards,

Joost.


_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.f
Christo
2018-07-02 20:19:19 UTC
Permalink
Post by Christo
I'm trying to figure out how to fix bug 33914. This bug causes gdb to read variable
addresses
from flash, not RAM.  Looking at the DWARF info, the address of a variable is written as a
word,
while gdb expects a prefixed address ($800000 + address) to indicate a RAM address, so the
size
of the address needs to be larger than 16 bits.  In dbgdwarf.pas it appears as if the size
of
addresses are taken from pint/puint in globtype.pas and aitconst_ptr_unaligned in
aasmtai.pas,
all of which are 16 bit sizes for AVR.
Of course all instances pint/puint types and aitconst_ptr_unaligned constants are appended
with
"_d" as part of this indirection.  A patch with this approach is attached to the bug report.
This appears to work correctly, but I'm not sure this is an elegant way of fixing the
problem.
Any comments or hints on how to fix the issue more elegantly?
Has been a long time ago, but my guess is that in some DWARF-header 
there is an offset for the memory-locations. (The unit-info maybe?)
I haven't noticed this in any header. It seems as if addresses are provided by the linker,
although I may be mistaken.
You should have a look at the Dwarf-specs. And maybe have a look at 
other platforms, what is generated there.
Thanks, I compared the generated assembly output of FPC and GCC, that is how I noticed the
discrepancy in address size and the sizes allocated to addresses.  Since the avr-gcc program
debugged fine, I tried to tweak the dbgdwarf unit to produce similar sized values.
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal

Loading...