Hi,

  I read at compiler/systems/i_embed.pas the AVR systeminfo, is the only one that, has as default "dbg : dbg_dwarf3". The other embed systems that uses dwarf ( ARM, MIPSEL, i8086, m68k, RISCV32/64, XTENSA, Z80 ), all have as default "dbg : dbg_dwarf2".

  The AVR has problems with dbg_dwarf2 ? If not, could you please change the AVR systeminfo to dwarf2 also for consistency ?

regards,

Hi,

  I'm sorry for noise. This was intended for the fpc-devel list. Apologies.

Στις 10/2/2021 12:47 μ.μ., ο/η Dimitrios Chr. Ioannidis έγραψε:

regards,

Hi,

  sorry for the noise ... ( again )

  My mail client messed up the "To:" labels and I thought that I mailed directly to C Western...

  Apologies.

regards,

On Wed, Feb 10, 2021 at 12:47 PM Dimitrios Chr. Ioannidis via fpc-devel <

That was a fix for compiling controller units with lots of symbols, refer to this discussion thread:

Dwarf2 is fine in general, unless the address (I think address in dwarf debug section, the details are a bit hazy in my memory) of symbols exceed
65535. Dwarf3 offers a larger data type for this scenario.

Hi,

Στις 10/2/2021 2:25 μ.μ., ο/η Christo Crause έγραψε:

 I'm using ppcrossavr with systeminfo default "dbg : dbg_dwarf2" with no problems. If I remember correctly, IMHO, fixing the issue 33914 ( https://bugs.freepascal.org/view.php?id=33914 ) had the collateral effect to fixing also the above.

 For test, I just debugged a physical atmega32u2 mcu with Lazarus with no for test, I builded an avr35 subarch ppcrossavr and also debugged a physical atmega32u2 mcu with no problems.

ppcrossavr ( from trunk ) builded on Windows 10 x64  ( with avr binutils 2.34  from https://blog.zakkemble.net/avr-gcc-builds/ ) :

make.exe clean crossall crossinstall CPU_TARGET=avr OS_TARGET=embedded SUBARCH=avr35 INSTALL_PREFIX=G:\Programming\dimitris\tools\ fpc-trunk CROSSOPT="-g -godwarfsets -gw2 -O1 -dDEBUG" CROSSBINDIR=G:\Programming\dimitris\tools\fpc-trunk\bin\x86_64-win64 BINUTILSPREFIX=avr-embedded-

regards,

Actually, the others should be better changed to dwarf3. Dwarf3 should be widely usable meanwhile, but maybe Martin can shed light on it.

On Wed, Feb 10, 2021 at 3:16 PM Dimitrios Chr. Ioannidis via fpc-devel <

You are probably right, I never checked if the pointer change of #33914 also fixed the original issue in the mailing list so the default dwarf version for AVR could be changed back to 2. But then Florian does have a point, why not make the default for all targets dwarf 3?

Hi,

Στις 10/2/2021 11:12 μ.μ., ο/η Christo Crause έγραψε:

I really don't know enough to have an opinion on this. As Florian wrote, Martin can answer this.

But if dwarf 3 is the default for avr, then IMHO, in avr link script generation are missing the following  :

===================================================================
--- t_embed.pas    (revision 48516)
+++ t_embed.pas    (working copy)
@@ -1074,6 +1074,11 @@
        Add('  .debug_str      0 : { *(.debug_str) }');
        Add('  .debug_loc      0 : { *(.debug_loc) }');
        Add('  .debug_macinfo  0 : { *(.debug_macinfo) }');
+      Add('  /* DWARF 3 */');
+      Add('  .debug_pubtypes 0 : { *(.debug_pubtypes) }');
+      Add('  .debug_ranges   0 : { *(.debug_ranges) }');
+      Add('  /* DWARF Extension.  */');
+      Add('  .debug_macro    0 : { *(.debug_macro) }');
        Add('}');
      end;
  {$endif AVR}

regards,

Indeed, thanks, I added it.