Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2018-06

AVR debug info - bug 0033914

3 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

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.

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?

Reply by email

Joost van der Sluis
to Christo

Op 30-06-18 om 21:51 schreef Christo:

Show quoted text 12 lines
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.

Reply by email

Christo
to Joost van der Sluis
Joost van der Sluis wrote 24 lines
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 ($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.

Reply by email