Re: [fpc-devel] AVR debug info - bug 0033914

2018-07-02 Thread Christo 
On Mon, 2018-07-02 at 15:47 +0200, Joost van der Sluis wrote:
> Op 30-06-18 om 21:51 schreef 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 ($80 + 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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] AVR debug info - bug 0033914

2018-07-02 Thread Joost van der Sluis 

Op 30-06-18 om 21:51 schreef 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 ($80 + 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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] AVR debug info - bug 0033914

2018-06-30 Thread 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 ($80 + 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-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel