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.