[fpc-devel] problem with dwarf inn fpc trunk (DW_AT_location)

[Martin]

fpc revision 25146 (windows 32 bit internal linker or -XE)

It seems that fpc does for some variable produce a DW_AT_location that 
no GDB (tested various from 6.3 to 7.5 on 32 bit win) understands. I do 
of course not know, if gdb is wrong, or fpc.


In Lazarus is a small app debugger\test\Gdbmi\TestApps\ArgVPrg.pas  
(also attached to the mail)
compiled with (using 2.6.2 and trunk)
    fpc.exe -gw -oArgVPas.exe  ArgVPrg.pas

then using
   objdump --dwarf

2.6.2
  <1><8f>: Abbrev Number: 2 (DW_TAG_variable)
     <90>   DW_AT_name        : S
     <92>   DW_AT_location    : 5 byte block: 3 20 90 42 0 (DW_OP_addr: 
429020)
     <98>   DW_AT_type        : <0x119>

trunk:
  <1><8f>: Abbrev Number: 2 (DW_TAG_variable)
     <90>   DW_AT_name        : S
     <92>   DW_AT_location    : 5 byte block: 3 20 0 0 0 (DW_OP_addr: 20)
     <98>   DW_AT_type        : <0x11f>

Seems the location in trunk is relative (maybe relocatable?)
But I can see no diff, in the exe
      objdump.exe -a  -f   Arg262.exe
Arg262.exe:     file format pei-i386
Arg262.exe
architecture: i386, flags 0x0000013a:
EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x00421a50

     objdump.exe -a  -f   Arg271.exe
Arg271.exe:     file format pei-i386
Arg271.exe
architecture: i386, flags 0x0000013a:
EXEC_P, HAS_DEBUG, HAS_SYMS, HAS_LOCALS, D_PAGED
start address 0x00422d80


gdb will try to access memory at the absolute address 0x00000020 and 
that fails.

Further, in a big apps with several 100 variables, about 20 have this 
error, and the rest are handled correct by gdb.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: ArgVPrg.pas
Type: text/x-pascal
Size: 415 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20130722/2d1862e8/attachment.pas>