Re: [fpc-devel] parentfp changed to $parentfp
On 09 Dec 2010, at 00:59, Martin wrote: On 08 Dec 2010, at 22:53, Jonas Maebe wrote: Also, unless you are using a GDB version shipped with the latest Fedora, or built one yourself from GDB's Archer git repository, using -gw3 is only going to cause problems: a) it's not nearly as well tested as -gw2 b) it uses a bunch of DWARF features that are not supported by regular GDB releases yet I am not using it for production. But I am doing some testing on the IDE's gdb interface. So I try to run the same apps with -gs, -gw, -gw3, compiled by different fpc versions, in different gdb versions... -gw3 should only be used to test the compiler's DWARF3 output at this point. Changing an IDE based on that is not useful because -gw3 itself is not stable (so you may have to change the IDE again in the future, or add workarounds for bugs that will never make it to a released FPC version resulting unnecessary bulky code). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] parentfp changed to $parentfp
On 09 Dec 2010, at 10:55, Jonas Maebe wrote: Changing an IDE based on that is not useful because -gw3 itself is not stable (so you may have to change the IDE again in the future, or add workarounds for bugs that will never make it to a released FPC version resulting unnecessary bulky code). Correction: that will never make to an FPC version that has release- quality DWARF3 support. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] difference between stabs and dwarf for var param
I found that for: procedure Foo(var AVal1: integer); The value for AVal is correctly shown with stabs, but not with dwarf. (See below). Is this a bug, and is it worth a bug report? Results below for fpc 2.4.2 (but same for trunk) With GDB 7.2-1 on W32 (but similar with other recent gdb versions) I understand that a var param is passed by ref (internally), but if Stabs can tell the debugger, to hide this, then shouldn't dwarf be able to do that too? Or is dwarf showing the internal pointer intentionally? If it is intention: Is there a way to distinguis between a user defined pointer (Aval1: PInteger) and the internal pointer (var AVal1: Integer) ? 2.4.2 / 7.2 / Stabs Executing (Recurse-Count=1) queued= 0: TGDBMIDebuggerCommandEvaluate: AVal1 State=Pause PauseWaitState=0 TCmdLineDebugger.SendCmdLn -data-evaluate-expression AVal1 TCmdLineDebugger.ReadLn ^done,value=10 TCmdLineDebugger.ReadLn (gdb) TCmdLineDebugger.SendCmdLn ptype AVal1 TCmdLineDebugger.ReadLn ptype AVal1\n [Debugger] Log output: ptype AVal1\n TCmdLineDebugger.ReadLn ~type = LONGINT\n TCmdLineDebugger.ReadLn ^done TCmdLineDebugger.ReadLn (gdb) Exec done 2.4.2 / 7.2 / Dwarf Executing (Recurse-Count=1) queued= 0: TGDBMIDebuggerCommandEvaluate: AVal1 State=Pause PauseWaitState=0 TCmdLineDebugger.SendCmdLn -data-evaluate-expression AVal1 TCmdLineDebugger.ReadLn ^done,value=@0x14cff34 TCmdLineDebugger.ReadLn (gdb) TCmdLineDebugger.SendCmdLn ptype AVal1 TCmdLineDebugger.ReadLn ptype AVal1\n [Debugger] Log output: ptype AVal1\n TCmdLineDebugger.ReadLn ~type = LONGINT\n TCmdLineDebugger.ReadLn ^done TCmdLineDebugger.ReadLn (gdb) Exec done ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] difference between stabs and dwarf for var param
On 09 Dec 2010, at 17:40, Martin wrote: I understand that a var param is passed by ref (internally), but if Stabs can tell the debugger, to hide this, then shouldn't dwarf be able to do that too? Or is dwarf showing the internal pointer intentionally? GDB does not yet support the concept of var parameters in DWARF, so we currently encode them as C++-style reference parameters. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] difference between stabs and dwarf for var param
I even had to revert a patch inside GDB about this issue, see: http://sourceware.org/ml/gdb-patches/2010-11/msg00084.html after my accepted patch: http://sourceware.org/ml/gdb-patches/2010-05/msg00258.html It seems that DW_AT_variable_parameter is an informational attribute only, and as such should only be used for display, but the fact that it is a parameter that is passed by reference should still be mentioned. If we issue both, then we should probably, inside the pascal expression reader, hide the reference, so that the output is the same as for stabs. Pierre Muller as pascal language maintainer of GDB. -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Jonas Maebe Envoyé : jeudi 9 décembre 2010 17:59 À : FPC developers' list Objet : Re: [fpc-devel] difference between stabs and dwarf for var param On 09 Dec 2010, at 17:40, Martin wrote: I understand that a var param is passed by ref (internally), but if Stabs can tell the debugger, to hide this, then shouldn't dwarf be able to do that too? Or is dwarf showing the internal pointer intentionally? GDB does not yet support the concept of var parameters in DWARF, so we currently encode them as C++-style reference parameters. Jonas___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] difference between stabs and dwarf for var param
On 09 Dec 2010, at 18:08, Pierre Free Pascal wrote: It seems that DW_AT_variable_parameter is an informational attribute only, and as such should only be used for display, but the fact that it is a parameter that is passed by reference should still be mentioned. If we issue both, then we should probably, inside the pascal expression reader, hide the reference, so that the output is the same as for stabs. I think that sounds like a good idea. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] win32 trunk gdb 7.2 (32bit) and qword error
On 10/12/2010 04:58, Martin wrote: This may well be an error in gdb, but since I can't determine where exactly the error is...: If I debug a 32 bit app (on w32) compiled with trunk (maybe 3 weeks old), under gdb 7.2-1 and hit a qword: Then I get the high and low 32bits swapped. so instead of a value of 1 gdb reports 0x1 Does anyone know if thats gdb, or something on how fpc wrote the dwarf info (-gw) ? Ok, and it seems to depend on the value 139784704 / 0x854F200 = bad 139784871 / 0x854F2A7 = good Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Infodwrf crashes, because apparently invalid dwarf info in file
Before I write a bug report, without having any data at all, maybe
someone can give me a hint how I may collect information that would make
sense
I've compile Lazarus with fpc rev 16374 (and external linker -Xe)
fpc(rtl) build with -gw
Lazarus with -gw -godwarfset
I have just freshly rebuild both enabling debug in Infodwrf
When trying to write a stacktrace I get a runtime error 131 from a very
long debug session, stepping by hand through the loop that loads every
tiny segment of a huge amount of dwarf info (I must have stepped
hundreds of times), I saw the following:
The value 131 in the stacktrace as param to seek = that is a replacment
that drops in due to the runtime error = before the runtime error (I
actually managed to step there) it was a huge value.
in PARSECOMPILATIONUNIT
DEBUG_WRITELN('Unit length: ', unit_length);
if (temp_length $) then begin
DEBUG_WRITELN('32 bit DWARF detected');
ReadNext(header32, sizeof(header32));
header32 (from after the crash only)
record TLINENUMBERPROGRAMHEADER32 {
UNIT_LENGTH = 0,
VERSION = 0,
LENGTH = 3972530176,
MINIMUM_INSTRUCTION_LENGTH = 221,
DEFAULT_IS_STMT = true (9),
LINE_BASE = -2,
LINE_RANGE = 173,
OPCODE_BASE = 65}
*IF* gdb reports that right
Below is the stacktrace (gdb has issues displaying the correct values in
some places)
and the end of the debug output DEBUG_DWARF_PARSER
Any ideas where and what to look for?
#0 HANDLEERRORADDRFRAME(165538076, 0x83, 0x9dde91c) at ..\inc\system.inc:940
#1 HANDLEERRORFRAME(131, 0x83) at ..\inc\system.inc:970
#2 fpc_iocheck at ..\inc\system.inc:682
#3 SEEK(18642842419200131) at ..\inc\lnfodwrf.pp:205
#4 PARSECOMPILATIONUNIT(131, 710980657026841489, @0x83: error reading
variable, @0x83: error reading variable, @0x83: error reading
variable) at ..\inc\lnfodwrf.pp:569
#5 GETLINEINFO(131, @0x423b91:
#199#5'0'#141'1'#1#0#0'f'#199#5'@'#141'1'#1#0#0#201#194#8#0#0#0#0#0#0#0#0#0#0'U'#137#229#131#236#8#137']'#248#187#255#255#255#255'f'#161'@'#141'1'#1'f;'#5'0'#141'1'#1'|ff'#199#5'@'#141'1'#1#0#0'f'#199#5'0'#141'1'#1'd'#0#139#21#144#141'1'#1#161#160#141'1'#1')'#194#15#191#5'0'#141'1'#1'9'#194'}'#19#161,
@0x83: error reading variable, @0x83: error reading variable) at
..\inc\lnfodwrf.pp:746
#6 DWARFBACKTRACESTR(0x9dde924) at ..\inc\lnfodwrf.pp:768
Current state : address = 00D5A690 file_id = 1 line = 38 column
= 1 is_stmt = TRUE basic_block = FALSE end_sequence = FALSE prolouge_end
= FALSE epiloug
e_begin = FALSE isa = 0
Unit length: 271
32 bit DWARF detected
Opcode parameter count table
Opcode[1] - 0 parameters
Opcode[2] - 1 parameters
Opcode[3] - 1 parameters
Opcode[4] - 1 parameters
Opcode[5] - 1 parameters
Opcode[6] - 0 parameters
Opcode[7] - 0 parameters
Opcode[8] - 0 parameters
Opcode[9] - 1 parameters
Opcode[10] - 0 parameters
Opcode[11] - 0 parameters
Opcode[12] - 1 parameters
Reading directories...
Reading filenames...
Skipping filename : sysinitpas.pp
Skipping LEB128 : 0
Skipping LEB128 : 0
Skipping LEB128 : 0
Next opcode:
DW_LNE_SET_ADDRESS (00DC0480)
Next opcode:
DW_LNS_SET_COLUMN (7)
Next opcode:
Special opcode $2B address increment: 0 new line: 31
Current state : address = 00DC0480 file_id = 1 line = 32 column
= 7 is_stmt = TRUE basic_block = FALSE end_sequence = FALSE prolouge_end
= FALSE epiloug
e_begin = FALSE isa = 0
Unit length: 4
32 bit DWARF detected
Opcode parameter count table
Opcode[1] - 0 parameters
Opcode[2] - 0 parameters
Opcode[3] - 0 parameters
Opcode[4] - 0 parameters
Opcode[5] - 0 parameters
Opcode[6] - 0 parameters
Opcode[7] - 0 parameters
Opcode[8] - 0 parameters
Opcode[9] - 0 parameters
Opcode[10] - 0 parameters
Opcode[11] - 0 parameters
Opcode[12] - 0 parameters
Opcode[13] - 0 parameters
Opcode[14] - 0 parameters
Opcode[15] - 0 parameters
Opcode[16] - 0 parameters
Opcode[17] - 0 parameters
Opcode[18] - 0 parameters
Opcode[19] - 0 parameters
Opcode[20] - 0 parameters
Opcode[21] - 0 parameters
Opcode[22] - 0 parameters
Opcode[23] - 0 parameters
Opcode[24] - 0 parameters
Opcode[25] - 0 parameters
Opcode[26] - 0 parameters
Opcode[27] - 0 parameters
Opcode[28] - 0 parameters
Opcode[29] - 0 parameters
Opcode[30] - 0 parameters
Opcode[31] - 0 parameters
Opcode[32] - 0 parameters
Opcode[33] - 0 parameters
Opcode[34] - 0 parameters
Opcode[35] - 0 parameters
Opcode[36] - 0 parameters
Opcode[37] - 0 parameters
Opcode[38] - 0 parameters
Opcode[39] - 0 parameters
Opcode[40] - 0 parameters
Opcode[41] - 0 parameters
Opcode[42] - 0 parameters
Opcode[43] - 0 parameters
Opcode[44] - 0 parameters
Opcode[45] - 0 parameters
Opcode[46] - 0 parameters
Opcode[47] - 0 parameters
Opcode[48] - 0 parameters
Opcode[49] - 0 parameters
Opcode[50] - 0 parameters
Opcode[51] - 0 parameters
Opcode[52] - 0 parameters
Opcode[53] - 0 parameters
Opcode[54] - 0 parameters
Opcode[55] - 0 parameters
Opcode[56] - 0 parameters
Opcode[57] - 0 parameters
Opcode[58] - 0 parameters
Opcode[59] - 0 parameters
Opcode[60] - 0 parameters
