On Mon, May 18, 2020 at 8:42 AM Christo Crause <christo.cra...@gmail.com> wrote:
> > On Sun, May 17, 2020 at 10:46 PM Dimitrios Chr. Ioannidis via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Hi, >> >> trying to debug an avr program, I got this error with fpc trunk : >> >> "Reading symbols from >> <PATH>\Projects\unit_depth_dwarf\unit_depth_dwarf.elf... >> Dwarf Error: Could not find abbrev number 18 in CU at offset 0x111d [in >> module >> G:\Programming\dimitris\Projects\unit_depth_dwarf\unit_depth_dwarf.elf] >> (No debugging symbols found in >> <PATH>\Projects\unit_depth_dwarf\unit_depth_dwarf.elf)" >> >> Investigating further, I found that when I declare an array type ( only >> ? I need to check further ... ) in a unit that is referenced from >> another unit which in turn is referenced from the main program, I get >> the error, i.e. : >> >> depth_2.pas unit -> has a type declared as an array >> >> depth_1.pas unit -> uses depth_2 unit and declares a variable with the >> type from the unit depth_2 >> >> main.pas -> uses depth_1 only >> >> in such scenario I get the dwarf error . >> > > Looking at the compiler generated assembler (-a) the information is > emitted, but doesn't end up in the final elf. This raises the suspicion > that it is the linker that is dropping the whole of the 2nd unit's debug > information If you add a procedure to unit2 that gets referenced anywhere > else the information is retained in the elf. > A check of the dwarf info in unit_depth_dwarf_depth_2.o (avr-objdump -Wi unit_depth_dwarf_depth_2.o) shows that the dwarf info is there, it is just not linked into the final executable. Hence it is a linker problem in my opinion.
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
