On Wed, Feb 10, 2021 at 3:16 PM Dimitrios Chr. Ioannidis via fpc-devel < fpc-devel@lists.freepascal.org> wrote:
> Hi, > Στις 10/2/2021 2:25 μ.μ., ο/η Christo Crause έγραψε: > > On Wed, Feb 10, 2021 at 12:47 PM Dimitrios Chr. Ioannidis via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> 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 ? >> > > That was a fix for compiling controller units with lots of symbols, refer > to this discussion thread: > https://www.mail-archive.com/fpc-devel@lists.freepascal.org/msg35416.html > 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. > > 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 > problems at all. Also for test, I builded an avr35 subarch ppcrossavr and > also debugged a physical atmega32u2 mcu with no problems. > 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?
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
