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.
program ArgVPrg;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes, sysutils
{ you can add units after this };
var
i: Integer;
p: PChar;
s: String;
begin
s := '';
for i := 1 to argc - 1 do begin
p := (argv+i)^;
while p^ <> #0 do begin
s := s + IntToHex(ord(p^), 2);
inc(p);
end;
s := s + ' ';
end;
WriteLn(s);
end.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
