Re: [fpc-devel] Re: Debugger for FPC

[Michael Schnell]

AFAICT Delphi allows one to 'Evaluate' _all_ properties, but only
allow 'Watch' properties with read functions if 'Allow side effects in
new watches' is enabled.
  

That does not seem like a very good paradigm :(

FP/gdb/DWARF should be able to do better using a "pure" pattern. :)

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Flávio Etrusco]

>
> I still did not yet get any discussion rolling on the issue of "pure" read
> functions (that have no side-effect). The debugger might use a "pure" read
> function to show the property value, but it can't if the read function is
> not pure. gcc does know about pure functions, thus I suppose DWARF also does
> so. In gcc there is an appropriate procedure attribute that lets the
> programmer define a function as "pure" but I suppose that the compiler also
> can do this automatically.
>
> Delphi seems to do do something similar, as the debugger can show values for
> _some_ properties with read functions, but not for all of them. I suppose
> FPC can be made recognize many read functions as "pure" and thus instruct
> gdb to use the read functions to show the property value.
>
> -Michael

AFAICT Delphi allows one to 'Evaluate' _all_ properties, but only
allow 'Watch' properties with read functions if 'Allow side effects in
new watches' is enabled.

-Flávio
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

Michael Schnell wrote on di, 17 mrt 2009:


I still did not yet get any discussion rolling on the issue of "pure"
read functions (that have no side-effect).


I did discuss it in my first mail to this thread. It first requires  
the following two problems to be solved, and none is particularly easy:


***
There are also multiple reasons for this:
a) we, nor anyone else, has defined an extension for DWARF to support  
Object Pascal properties, let alone implemented support for it in a  
debugger (although that may not even be necessary, it's quite possible  
that current gdb features combined with a to be developed Lazarus  
DWARF reader would be enough)
b) by default, FPC uses the (completely non-standard, afaik) Delphi  
calling convention on i386 (different from GCC's fastcall), which is  
not supported by gdb (until someone adds support for it). Hence, once  
you add property support to the debugging format (and possibly the  
debugger), you still have to teach the debugger about how this calling  
convention works so it can properly evaluate expressions containing  
calls. This is fortunately less of a problem on other architectures.

***

a) could also be reformulated as "nobody has defined an extension for  
DWARF to describe calling functions", although that's more general  
(since the possible signatures of getters/setters are limited).



Jonas

Jonas


This message was sent using IMP, the Internet Messaging Program.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Michael Schnell]

b) a property with a read specifier that is a function call, but with a
write specifier directly going to a field? Nothing, 



Nothing for now imo.
  

That is what "pure" functions in C are defined for.

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Michael Schnell]

And in fact, the same can be done to generate for properties that 
directly map to variables/fields. Just one question: what should the 
debug information point the debugger to in case of
a) a property without a read specifier, but with a write specifier 
going directly to a field? Nothing, or that field?
b) a property with a read specifier that is a function call, but with 
a write specifier directly going to a field? Nothing, or that field? 
(as long as we do not support encoding property accessor function 
calls into the debug information, and/or when we do but determine that 
the accessor can have side effects)
I still did not yet get any discussion rolling on the issue of "pure" 
read functions (that have no side-effect). The debugger might use a 
"pure" read function to show the property value, but it can't if the 
read function is not pure. gcc does know about pure functions, thus I 
suppose DWARF also does so. In gcc there is an appropriate procedure 
attribute that lets the programmer define a function as "pure" but I 
suppose that the compiler also can do this automatically.


Delphi seems to do do something similar, as the debugger can show values 
for _some_ properties with read functions, but not for all of them. I 
suppose FPC can be made recognize many read functions as "pure" and thus 
instruct gdb to use the read functions to show the property value.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Schatzl Thomas wrote:


I checked that lnfodwrf.pp at least compiles on win32.


Stabs does not support 64 bit, DWARF is default on all these platforms, that's 
why it is used in win64 and not win32.

The lnfodwrf.pp should work fine on win32 though.


If so then please apply attached patch and regenerate apropriate makefile.

Best regards,
Paul Ishenin.
Index: rtl/win32/Makefile.fpc
===
--- rtl/win32/Makefile.fpc  (revision 12902)
+++ rtl/win32/Makefile.fpc  (working copy)
@@ -7,7 +7,7 @@
 
 [target]
 loaders=$(LOADERS)
-units=system objpas macpas buildrtl lineinfo
+units=system objpas macpas buildrtl lineinfo lnfodwrf
 implicitunits=sysinitpas sysinitcyg sysinitgprof \
   ctypes strings \
   heaptrc matrix \
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Paul Ishenin wrote:

Jonas Maebe wrote:
Maybe smart linking is enabled? I don't think it works yet with DWARF 
(I'll change the compiler it also disables that when using DWARF debug 
info).
No, it does not. I checked with fpc r12887 - still the same problem 
under gdb.


Today I tested on my ubuntu 8.10 and there it works fine. And btw, 
evaluation of simple properties also works very well.


But dwarf info on windows still needs to be fixed. I suspect about 50% 
of users are using windows to develop.


Best regards,
Paul Ishenin.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Sat, Mar 14, 2009 at 12:52 PM, Michael Van Canneyt
 wrote:
>>
>> But maybe it's easier to ask the usual question: wddd? (what does Delphi do)
>
> The watches window shows 'Cannot read a write-only property'.

Which seems quite logical to me as well. After all, it is a write-only property.


Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Schatzl Thomas]

Hello,

> Von: Paul Ishenin 
> Jonas Maebe wrote:
> >
> > It's the DWARF version of the lineinfo unit. It's only required to get 
> > line numbers in backtraces when a program crashes. Apparently, it 
> > hasn't been ported to Win32 yet, but it's not required to debug. Just 
> > leave out the -gl parameter.
> Btw, it is strange that in rtl\win64\makefile.fpc lnfodwrf is present 
> but in rtl\win32\makefile.fpc it does not.
> 
> I checked that lnfodwrf.pp at least compiles on win32.

Stabs does not support 64 bit, DWARF is default on all these platforms, that's 
why it is used in win64 and not win32.

The lnfodwrf.pp should work fine on win32 though.

Thomas

-- 
Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: 
http://www.gmx.net/de/go/multimessenger01
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Jonas Maebe wrote:
Maybe smart linking is enabled? I don't think it works yet with DWARF 
(I'll change the compiler it also disables that when using DWARF debug 
info).
No, it does not. I checked with fpc r12887 - still the same problem 
under gdb.


Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Jonas Maebe wrote:


It's the DWARF version of the lineinfo unit. It's only required to get 
line numbers in backtraces when a program crashes. Apparently, it 
hasn't been ported to Win32 yet, but it's not required to debug. Just 
leave out the -gl parameter.
Btw, it is strange that in rtl\win64\makefile.fpc lnfodwrf is present 
but in rtl\win32\makefile.fpc it does not.


I checked that lnfodwrf.pp at least compiles on win32.

Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 15:59, Paul Ishenin wrote:


Jonas Maebe wrote:
Strange, that error looks very much like the one that should have  
been fixed by http://bugs.freepascal.org/view.php?id=12872

Yes.

I tried to compile so (gdb complained the same way):
c:\programming\fpc\bin\i386-win32\ppc386.exe -Aas -gw test.pp
and fpc wrote me this note:
"Note: Switching assembler to default source writing assembler"

Maybe it switched back assembler from -Aas to "default" for some  
reason?


Maybe smart linking is enabled? I don't think it works yet with DWARF  
(I'll change the compiler it also disables that when using DWARF debug  
info).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 15:59, Paul Ishenin wrote:


Jonas Maebe wrote:
Strange, that error looks very much like the one that should have  
been fixed by http://bugs.freepascal.org/view.php?id=12872

Yes.

I tried to compile so (gdb complained the same way):
c:\programming\fpc\bin\i386-win32\ppc386.exe -Aas -gw test.pp
and fpc wrote me this note:
"Note: Switching assembler to default source writing assembler"

Maybe it switched back assembler from -Aas to "default" for some  
reason?


No, the compiler simply does not check whether the external assembler  
is already selected before writing that message:


  if (paratargetdbg in [dbg_dwarf2,dbg_dwarf3]) and
 (target_info.system = system_i386_win32) then
begin
 Message(option_switch_bin_to_src_assembler);
 set_target_asm(target_info.assemextern);
end;


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 15:27, Paul Ishenin wrote:


Jonas Maebe wrote:


It's the DWARF version of the lineinfo unit. It's only required to  
get line numbers in backtraces when a program crashes. Apparently,  
it hasn't been ported to Win32 yet, but it's not required to debug.  
Just leave out the -gl parameter.
Ok, I tried to fix it by changing makefile in the rtl\win32  
directory but then gdb complained about dwarf offsets.


That's known for Windows and DWARF2, because nobody really ever tested/ 
fixed DWARF2 support in the compiler for Windows (and I can't do it).  
According to http://bugs.freepascal.org/view.php?id=12872, it should  
however work.


See Tomas' mail for why your test didn't work. With -gl, the compiler  
(still) uses stabs. Also note that some cases (the ones outlined in my  
comment at http://bugs.freepascal.org/view.php?id=13313 ) absolute  
references probably won't work yet with -Xg. The reason why is  
explained here: http://sourceware.org/ml/gdb/2009-03/msg00085.html



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Jonas Maebe wrote:
Strange, that error looks very much like the one that should have been 
fixed by http://bugs.freepascal.org/view.php?id=12872

Yes.

I tried to compile so (gdb complained the same way):
c:\programming\fpc\bin\i386-win32\ppc386.exe -Aas -gw test.pp
and fpc wrote me this note:
"Note: Switching assembler to default source writing assembler"

Maybe it switched back assembler from -Aas to "default" for some reason?

Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 15:42, Paul Ishenin wrote:


Tomas Hajny wrote:

Keeping -gl instead of -gw?


Sorry, "leave out" was not in my head dictionary :)

c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp

(gdb) break test.pp:8
invalid dwarf2 offset 4243567

No luck :(


Strange, that error looks very much like the one that should have been  
fixed by http://bugs.freepascal.org/view.php?id=12872



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Tomas Hajny wrote:

Keeping -gl instead of -gw?
  

Sorry, "leave out" was not in my head dictionary :)

c:\programming\fpc\bin\i386-win32\ppc386.exe -gw test.pp

(gdb) break test.pp:8
invalid dwarf2 offset 4243567

No luck :(

Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Tomas Hajny]

On 14 Mar 09, at 21:27, Paul Ishenin wrote:
> Jonas Maebe wrote:
> >
> > It's the DWARF version of the lineinfo unit. It's only required to get 
> > line numbers in backtraces when a program crashes. Apparently, it 
> > hasn't been ported to Win32 yet, but it's not required to debug. Just 
> > leave out the -gl parameter.
> Ok, I tried to fix it by changing makefile in the rtl\win32 directory 
> but then gdb complained about dwarf offsets.
> 
> Anyway, I tried to test attached source file.
> 
> c:\programming\fpc\bin\i386-win32\ppc386.exe -O1 -gl test.pp
> 
> 
> Here is my gdb log:
> [log]
> C:\1>C:\programming\lazaraus-binaries\i386-win32\gdb\bin\gdb.exe test.exe
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-pc-mingw32"...
> (gdb) break test.pp:8
> Breakpoint 1 at 0x401427: file test.pp, line 8.
> (gdb) run
> Starting program: C:\1/test.exe
> [New thread 2024.0x1278]
> 
> Breakpoint 1, main () at test.pp:8
> 8 WriteLn(z);
> (gdb) print a
> $1 = 4
> (gdb) print z
> No symbol "z" in current context.
> (gdb) continue
> Continuing.
> 4
> [/log]
> 
> What I'm doing wrong?

Keeping -gl instead of -gw?

Tomas

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Jonas Maebe wrote:


It's the DWARF version of the lineinfo unit. It's only required to get 
line numbers in backtraces when a program crashes. Apparently, it 
hasn't been ported to Win32 yet, but it's not required to debug. Just 
leave out the -gl parameter.
Ok, I tried to fix it by changing makefile in the rtl\win32 directory 
but then gdb complained about dwarf offsets.


Anyway, I tried to test attached source file.

c:\programming\fpc\bin\i386-win32\ppc386.exe -O1 -gl test.pp


Here is my gdb log:
[log]
C:\1>C:\programming\lazaraus-binaries\i386-win32\gdb\bin\gdb.exe test.exe
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...
(gdb) break test.pp:8
Breakpoint 1 at 0x401427: file test.pp, line 8.
(gdb) run
Starting program: C:\1/test.exe
[New thread 2024.0x1278]

Breakpoint 1, main () at test.pp:8
8 WriteLn(z);
(gdb) print a
$1 = 4
(gdb) print z
No symbol "z" in current context.
(gdb) continue
Continuing.
4
[/log]

What I'm doing wrong?

Best regards,
Paul Ishenin.
program test;
{$apptype console}
var
  a: integer;
  z: integer absolute a;
begin
  a := 4;
  WriteLn(z);
end.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 15:00, Paul Ishenin wrote:


Jonas Maebe wrote:




Ok, thanks. Support for DWARF2 debug info for properties with an  
accessor that does not pass via a function is committed.


I'm glad to check it but how (fpc r12883)?

c:\programming\fpc\bin\i386-win32\ppc386.exe -O1 -gl -gw test.pp

Note: Switching assembler to default source writing assembler
Free Pascal Compiler version 2.3.1 [2009/03/14] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling test.pp
Fatal: Can't find unit lnfodwrf used by test
Fatal: Compilation aborted

What is lnfodwrf?


It's the DWARF version of the lineinfo unit. It's only required to get  
line numbers in backtraces when a program crashes. Apparently, it  
hasn't been ported to Win32 yet, but it's not required to debug. Just  
leave out the -gl parameter.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Jonas Maebe wrote:


On 14 Mar 2009, at 11:52, Michael Van Canneyt wrote:


The watches window shows 'Cannot read a write-only property'.


Ok, thanks. Support for DWARF2 debug info for properties with an 
accessor that does not pass via a function is committed.


I'm glad to check it but how (fpc r12883)?

c:\programming\fpc\bin\i386-win32\ppc386.exe -O1 -gl -gw test.pp

Note: Switching assembler to default source writing assembler
Free Pascal Compiler version 2.3.1 [2009/03/14] for i386
Copyright (c) 1993-2009 by Florian Klaempfl
Target OS: Win32 for i386
Compiling test.pp
Fatal: Can't find unit lnfodwrf used by test
Fatal: Compilation aborted

What is lnfodwrf?

Best regards,
Paul Ishenin.
program test;
{$apptype console}
var
  a: integer;
begin
  a := 4;
  WriteLn(a);
end.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 11:52, Michael Van Canneyt wrote:


The watches window shows 'Cannot read a write-only property'.


Ok, thanks. Support for DWARF2 debug info for properties with an  
accessor that does not pass via a function is committed.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Michael Van Canneyt]

On Sat, 14 Mar 2009, Jonas Maebe wrote:

> 
> On 14 Mar 2009, at 11:32, Luca Olivetti wrote:
> 
> >El Sat, 14 Mar 2009 10:42:14 +0100
> >Florian Klaempfl  escribió:
> >
> > > >a) a property without a read specifier, but with a write specifier
> > > >going directly to a field? Nothing, or that field?
> > >
> > >Nothing. This property is not readable.
> >
> >It's not readable by the users of the class, but it should be readable
> >to someone debugging it.
> 
> The field it refers to is readable in any case. The question is whether they
> should also be able to use something like "print write_only_property".
> Moreover, once support for calling getters/setters is implemented, for
> consistency purposes a write-only property with a setter should then also be
> printable. However, there is not way to do that, since you cannot do "print
> property_setter" (since a setter does not return any value).
> 
> But maybe it's easier to ask the usual question: wddd? (what does Delphi do)

The watches window shows 'Cannot read a write-only property'.

Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 11:32, Luca Olivetti wrote:


El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl  escribió:


a) a property without a read specifier, but with a write specifier
going directly to a field? Nothing, or that field?


Nothing. This property is not readable.


It's not readable by the users of the class, but it should be readable
to someone debugging it.


The field it refers to is readable in any case. The question is  
whether they should also be able to use something like "print  
write_only_property". Moreover, once support for calling getters/ 
setters is implemented, for consistency purposes a write-only property  
with a setter should then also be printable. However, there is not way  
to do that, since you cannot do "print property_setter" (since a  
setter does not return any value).


But maybe it's easier to ask the usual question: wddd? (what does  
Delphi do)



Jonas___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Luca Olivetti]

El Sat, 14 Mar 2009 10:42:14 +0100
Florian Klaempfl  escribió:

> > a) a property without a read specifier, but with a write specifier
> > going directly to a field? Nothing, or that field?
> 
> Nothing. This property is not readable.

It's not readable by the users of the class, but it should be readable
to someone debugging it.

Bye
-- 
Luca
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 10:42, Florian Klaempfl wrote:


Jonas Maebe schrieb:


It turned out that DWARF2 was enough, so the implementation should
already work with currently released GDB versions (see
http://bugs.freepascal.org/view.php?id=13313 for some caveats).

And in fact, the same can be done to generate for properties that
directly map to variables/fields. Just one question: what should the
debug information point the debugger to in case of
a) a property without a read specifier, but with a write specifier  
going

directly to a field? Nothing, or that field?


Nothing. This property is not readable.

b) a property with a read specifier that is a function call, but  
with a

write specifier directly going to a field? Nothing,


Nothing for now imo.


Ok.


or that field? (as
long as we do not support encoding property accessor function calls  
into
the debug information, and/or when we do but determine that the  
accessor

can have side effects)


Can this be done with dwarf?


Not at this time (except by using a custom extension). We should write  
a proposal for DWARF4 and submit it using http://dwarfstd.org/Comment.php 
 (see http://dwarfstd.org/Issues.php and the links to the issues  
closed for Version 3 and 4 for some ideas about how to write such a  
proposal).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Florian Klaempfl]

Jonas Maebe schrieb:
> 
> On 11 Mar 2009, at 15:12, Jonas Maebe wrote:
> 
>> It may even be quite challenging to generate debug information for
>> something like that with Stabs. For DWARF, it seems there is some code
>> that generates debug information in some cases, but only for "var a:
>> type absolute b;"-style expressions (although I can't even trigger
>> that at first sight).
>>
>> With DWARF3, this should also be quite doable.
> 
> It turned out that DWARF2 was enough, so the implementation should
> already work with currently released GDB versions (see
> http://bugs.freepascal.org/view.php?id=13313 for some caveats).
> 
> And in fact, the same can be done to generate for properties that
> directly map to variables/fields. Just one question: what should the
> debug information point the debugger to in case of
> a) a property without a read specifier, but with a write specifier going
> directly to a field? Nothing, or that field?

Nothing. This property is not readable.

> b) a property with a read specifier that is a function call, but with a
> write specifier directly going to a field? Nothing, 

Nothing for now imo.

> or that field? (as
> long as we do not support encoding property accessor function calls into
> the debug information, and/or when we do but determine that the accessor
> can have side effects)

Can this be done with dwarf?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 09:46, dmitry boyarintsev wrote:

No, it's guaranteeing future compatibility, because by using a  
property you

ensure that you can later on replace the setter with a procedure if
necessary, without breaking existing source code (at least in FPC  
2.3.1; FPC
2.2.x misses several checks, allowing you to do all sorts of things  
with

properties directly mapped to fields that should not be possible).


but, if reading a property is bound to a field. and setting is bound
to a setting procedure.
Changing the property is incorrect by writting into the field, instead
of calling the setting procedure.


You mean changing the property by using the debugger? Then, yes, but I  
don't consider that a big problem at this time. Currently, you can  
choose between having no debug information at all, or the ability to  
potentially wrongly change a property.



btw, is there an information about string processing functions? (i
guess it can be included if rebuild rtl with debug info).
for example, when debugging strings (ansi or wide, not shortstrings)
it's necessary to change their values, using string processing
functions, instead of changing their values as PChar or PWideChar?
AFAIK, gdb is not aware of it, and treats strings as PChar?

for example:
var
 a, b : AnsiString;
begin
 a := 'hello';
 b := a;
 writeln(a); // i set a break point here, and change a value to  
'hello world';

 writeln(b); // b should not change.
end;

AFAIK, setting values is not implemented is Lazarus yet, but will be  
in future.

This way of value changing works in delphi.
To set the string value, it's necessary to know the string setting
procedure address, can this additional information be added to DWARF
too? so debugger can use it if necessary?


No, that would require extensions to the debug info format.


Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[dmitry boyarintsev]

> No, it's guaranteeing future compatibility, because by using a property you
> ensure that you can later on replace the setter with a procedure if
> necessary, without breaking existing source code (at least in FPC 2.3.1; FPC
> 2.2.x misses several checks, allowing you to do all sorts of things with
> properties directly mapped to fields that should not be possible).

but, if reading a property is bound to a field. and setting is bound
to a setting procedure.
Changing the property is incorrect by writting into the field, instead
of calling the setting procedure.

btw, is there an information about string processing functions? (i
guess it can be included if rebuild rtl with debug info).
for example, when debugging strings (ansi or wide, not shortstrings)
it's necessary to change their values, using string processing
functions, instead of changing their values as PChar or PWideChar?
AFAIK, gdb is not aware of it, and treats strings as PChar?

for example:
var
  a, b : AnsiString;
begin
  a := 'hello';
  b := a;
  writeln(a); // i set a break point here, and change a value to 'hello world';
  writeln(b); // b should not change.
end;

AFAIK, setting values is not implemented is Lazarus yet, but will be in future.
This way of value changing works in delphi.
To set the string value, it's necessary to know the string setting
procedure address, can this additional information be added to DWARF
too? so debugger can use it if necessary?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 09:16, dmitry boyarintsev wrote:


writing a property directly in the field is a hack


No, it's guaranteeing future compatibility, because by using a  
property you ensure that you can later on replace the setter with a  
procedure if necessary, without breaking existing source code (at  
least in FPC 2.3.1; FPC 2.2.x misses several checks, allowing you to  
do all sorts of things with properties directly mapped to fields that  
should not be possible).



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 14 Mar 2009, at 09:16, dmitry boyarintsev wrote:

And in fact, the same can be done to generate for properties that  
directly

map to variables/fields. Just one question: what should the debug
information point the debugger to in case of
a) a property without a read specifier, but with a write specifier  
going

directly to a field? Nothing, or that field?
b) a property with a read specifier that is a function call, but  
with a
write specifier directly going to a field? Nothing, or that field?  
(as long
as we do not support encoding property accessor function calls into  
the
debug information, and/or when we do but determine that the  
accessor can

have side effects)


how about:
c) a property with a read specifier and write specifier?


I didn't mention that because if the read specifier is just a field,  
then the debug info should obviously simply point to that field (when  
you ask the debugger for the value of a property, I think you'd  
normally expect it to give you the value that you'd get when reading  
the property). And if it's a function, it's not yet possible to call  
it at this time.



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[dmitry boyarintsev]

> And in fact, the same can be done to generate for properties that directly
> map to variables/fields. Just one question: what should the debug
> information point the debugger to in case of
> a) a property without a read specifier, but with a write specifier going
> directly to a field? Nothing, or that field?
> b) a property with a read specifier that is a function call, but with a
> write specifier directly going to a field? Nothing, or that field? (as long
> as we do not support encoding property accessor function calls into the
> debug information, and/or when we do but determine that the accessor can
> have side effects)

how about:
c) a property with a read specifier and write specifier?

writing a property directly in the field is a hack, writing property
using setting procedure is correct way, with excpected "side-effects".

Thanks,
Dmitry
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

On 11 Mar 2009, at 15:12, Jonas Maebe wrote:

It may even be quite challenging to generate debug information for  
something like that with Stabs. For DWARF, it seems there is some  
code that generates debug information in some cases, but only for  
"var a: type absolute b;"-style expressions (although I can't even  
trigger that at first sight).


With DWARF3, this should also be quite doable.


It turned out that DWARF2 was enough, so the implementation should  
already work with currently released GDB versions (see http://bugs.freepascal.org/view.php?id=13313 
 for some caveats).


And in fact, the same can be done to generate for properties that  
directly map to variables/fields. Just one question: what should the  
debug information point the debugger to in case of
a) a property without a read specifier, but with a write specifier  
going directly to a field? Nothing, or that field?
b) a property with a read specifier that is a function call, but with  
a write specifier directly going to a field? Nothing, or that field?  
(as long as we do not support encoding property accessor function  
calls into the debug information, and/or when we do but determine that  
the accessor can have side effects)



Jonas
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Thu, Mar 12, 2009 at 10:53 AM, Jonas Maebe  wrote:
> I've also never seen a bug report about this fact. And although I realise
> that it may not be obvious that some variable is not visible due to the fact
> that it's an absolute variable, simply a bug report about "variable x of
> unit y is not visible to the debugger" would have been enough.


There is one now!

http://bugs.freepascal.org/view.php?id=13313



Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Michael Van Canneyt]

On Thu, 12 Mar 2009, Vincent Snijders wrote:

> Jonas Maebe schreef:
> > Vincent Snijders wrote on do, 12 mrt 2009:
> > 
> > > I guess the fpc developers traded debuggability for maintainability, so
> > > you could have a better fpc (more features or less bugs). That is what
> > > it concerns to you as developer. Maybe you disagree with that trade off.
> > 
> > No, it's simply an unimplemented feature. In fact, I for one didn't even
> > realise that absolute variables were not included in the debug information
> > (they're not used that much in the compiler itself).
> 
> I was referring to the fact that the FPC RTL uses an absolute variable
> Var
> 
>{ Character to be put between date, month and year }
>DateSeparator: char absolute DefaultFormatSettings.DateSeparator;
> 
> instead of just
> Var
>   DateSepator: char.
> 
> I speculated that is was to have more maintainable code, so. The drawback is
> that you cannot view the contents, because the compiler doesn't seem to
> generate the correct debug info for it (yet).
> 
> Apparently this trade off has been made unconsciously.

The construct with absolute was necessary to fix some other bugs/features in
a more or less efficient manner. The debugging issue was never even
considered. 

Michael.

> 
> > 
> > I've also never seen a bug report about this fact. And although I realise
> > that it may not be obvious that some variable is not visible due to the fact
> > that it's an absolute variable, simply a bug report about "variable x of
> > unit y is not visible to the debugger" would have been enough.
> 
> Who volunteers to create it?
> 
> > 
> > So when something does not work in the debugger, do not automatically assume
> > that it's because GDB is supposedly so bad. It may just as well be a bug in
> > the compiler.
> > 
> 
> I did not, it was clear from earlier posts, that it the compiler doesn't
> write out this information (yet). OTOH, I did not know this a week ago and
> would have blamed Lazarus' interface with the debugger. ;-)
> 
> Vincent
> 
> 
> ___
> 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] Re: Debugger for FPC

[Vincent Snijders]

Jonas Maebe schreef:

Vincent Snijders wrote on do, 12 mrt 2009:


I guess the fpc developers traded debuggability for maintainability, so
you could have a better fpc (more features or less bugs). That is what
it concerns to you as developer. Maybe you disagree with that trade off.


No, it's simply an unimplemented feature. In fact, I for one didn't even 
realise that absolute variables were not included in the debug 
information (they're not used that much in the compiler itself).


I was referring to the fact that the FPC RTL uses an absolute variable
Var

   { Character to be put between date, month and year }
   DateSeparator: char absolute DefaultFormatSettings.DateSeparator;

instead of just
Var
  DateSepator: char.

I speculated that is was to have more maintainable code, so. The 
drawback is that you cannot view the contents, because the compiler 
doesn't seem to generate the correct debug info for it (yet).


Apparently this trade off has been made unconsciously.



I've also never seen a bug report about this fact. And although I 
realise that it may not be obvious that some variable is not visible due 
to the fact that it's an absolute variable, simply a bug report about 
"variable x of unit y is not visible to the debugger" would have been 
enough.


Who volunteers to create it?



So when something does not work in the debugger, do not automatically 
assume that it's because GDB is supposedly so bad. It may just as well 
be a bug in the compiler.




I did not, it was clear from earlier posts, that it the compiler doesn't 
 write out this information (yet). OTOH, I did not know this a week ago 
and would have blamed Lazarus' interface with the debugger. ;-)


Vincent


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

Vincent Snijders wrote on do, 12 mrt 2009:


I guess the fpc developers traded debuggability for maintainability, so
you could have a better fpc (more features or less bugs). That is what
it concerns to you as developer. Maybe you disagree with that trade off.


No, it's simply an unimplemented feature. In fact, I for one didn't  
even realise that absolute variables were not included in the debug  
information (they're not used that much in the compiler itself).


I've also never seen a bug report about this fact. And although I  
realise that it may not be obvious that some variable is not visible  
due to the fact that it's an absolute variable, simply a bug report  
about "variable x of unit y is not visible to the debugger" would have  
been enough.


So when something does not work in the debugger, do not automatically  
assume that it's because GDB is supposedly so bad. It may just as well  
be a bug in the compiler.



Jonas


This message was sent using IMP, the Internet Messaging Program.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Daniël Mantione]

Op Thu, 12 Mar 2009, schreef Vincent Snijders:


Graeme Geldenhuys schreef:

On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber  wrote:
Delphi/Kylix probably can't map a variable to the address of another 
variable,

because of that Delphi needs separate implementations of format functions
with and without FormatSettings parameter.


To be honest that is not my concern... As a developer I simply use
ShortDateFormat and that's it.



I guess the fpc developers traded debuggability for maintainability, so you 
could have a better fpc (more features or less bugs). That is what it 
concerns to you as developer. Maybe you disagree with that trade off.


The GDB with all its cryptic stabs is not the most maintainable code of 
the compiler so it's definately not a maintenance trade-off. In fact, 
better debugaability would make maintenace of the compiler easier as well;
the compiler remains an incredibly complex piece of technology that isn't always 
trivial to debug.


Daniël___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Thu, Mar 12, 2009 at 10:22 AM, Vincent Snijders
 wrote:
>
> I guess the fpc developers traded debuggability for maintainability, so you
> could have a better fpc (more features or less bugs). That is what it
> concerns to you as developer. Maybe you disagree with that trade off.

I did not mean any disrespect to the FPC developers. I simply tried to
make the point that as an application developer, you would only use
'ShortDateFormat' in your applications. So one would expect to only
have to use that variable in debugging and not the fully qualified
name 'DefaultFormatSettings.ShortDateFormat' as Martin suggested.

I do not see it as convenient or logical to have one format for usage
in applications and a different format for debugging. This breaks
tooltip evaluation in any IDE as well! Hence the reason I use resorted
to log files for debugging. I only have to use a single format no
matter what I am debugging - locale variables, object properties,
nested methods with it's local variable etc

I love to promote Lazarus and FPC, but when somebody in the CodeGear
newsgroup mentioned the flaws in trying to debug FPC applications, I
was dumb founded and didn't have a snappy answer. Then it dawned on me
- I got so used to debugging via log files, I forgot how easy and
convenient it is under Kylix and Delphi.  I am wasting such a lot of
time adding Log(...) calls in my code and then later having to remove
them after the bug was fixed, or wrap them in ugly {$IFDEF DEBUG}
calls.

Having a fully working debugger must take some priority and hence my
willingness to learn about debuggers and try and help coding up
something that works. It will save myself and others a lot of time in
future projects. FPC is not just a hobby to me, it's the tool I use to
make a living!

Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Vincent Snijders]

Graeme Geldenhuys schreef:

On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber  wrote:

Delphi/Kylix probably can't map a variable to the address of another variable,
because of that Delphi needs separate implementations of format functions
with and without FormatSettings parameter.


To be honest that is not my concern... As a developer I simply use
ShortDateFormat and that's it.



I guess the fpc developers traded debuggability for maintainability, so 
you could have a better fpc (more features or less bugs). That is what 
it concerns to you as developer. Maybe you disagree with that trade off.


Vincent
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Wed, Mar 11, 2009 at 6:11 PM, Martin Schreiber  wrote:
> Delphi/Kylix probably can't map a variable to the address of another variable,
> because of that Delphi needs separate implementations of format functions
> with and without FormatSettings parameter.

To be honest that is not my concern... As a developer I simply use
ShortDateFormat and that's it.


> Use "DefaultFormatSettings.ShortDateFormat" to display the value in gdb.

But that's the whole point, you shouldn't need to. I don't use
"DefaultFormatSettings.ShortDateFormat" in my code, I simply use
"ShortDateFormat". Why must I learn one way for debugging and one for
actual coding! To 99.9% of developers the ShortDateFormat is simply a
string type variable and they want to debug that variable like all
other string type variables.

Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Martin Schreiber]

On Wednesday 11 March 2009 15:14:27 Graeme Geldenhuys wrote:
> On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
>
>  wrote:
> >  http://opensoft.homeip.net/~graemeg/gdb_issues_with_fpc.png
>
> And then the same think under Kylix 3. As I said, with Delphi and
> Kylix such trivial things is a no-brainer. Debugging just works.
>
> http://opensoft.homeip.net/~graemeg/kylix_debuging.png
>
>
Delphi/Kylix:
"
var
  CurrencyString: string;
  CurrencyFormat: Byte;
  NegCurrFormat: Byte;
  ThousandSeparator: Char;
  DecimalSeparator: Char;
  CurrencyDecimals: Byte;
  DateSeparator: Char;
  ShortDateFormat: string;
"
FPC:
"
Var

   { Character to be put between date, month and year }
   DateSeparator: char absolute DefaultFormatSettings.DateSeparator;

   { Format used for short date notation }
   ShortDateFormat: string absolute DefaultFormatSettings.ShortDateFormat;
"
Delphi/Kylix probably can't map a variable to the address of another variable, 
because of that Delphi needs separate implementations of format functions 
with and without FormatSettings parameter.

Use "DefaultFormatSettings.ShortDateFormat" to display the value in gdb.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

Michael Schnell wrote on wo, 11 mrt 2009:

To make FPC generate DWARF3 debug info, use the -gw3 command line   
switch. Note that this is not yet very well tested, and may still   
contain a lot of bugs (with things working with -g and/or -gw2 not   
working with -gw3)

But it seems the way FP goes is already defined and seems like appropriate.


The way I go is already defined (GDB + submitting GDB patches when  
necessary + DWARF3).


That does not mean everyone in the FPC team agrees with me though  
(well, I know for a fact that not everyone does :). However,  
regardless of whether someone uses GDB or a new debugger, proper and  
full DWARF3 support in the compiler is pretty much required by  
definition.



I suppose Lazarus needs an update, too, as it needs to support the
upcoming features of the DWARF3 aware debugger.


In general, not that many changes to Lazarys should be required. Most  
of the differences will be that previously wrong variable values will  
become correct (e.g., dynamic arrays), or that unknown variables will  
become known (e.g., absolute variables). Only if Lazarus contains some  
workarounds for certain cases, then those workarounds may need to be  
disabled.



Jonas


This message was sent using IMP, the Internet Messaging Program.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Michael Schnell]

To make FPC generate DWARF3 debug info, use the -gw3 command line 
switch. Note that this is not yet very well tested, and may still 
contain a lot of bugs (with things working with -g and/or -gw2 not 
working with -gw3)

But it seems the way FP goes is already defined and seems like appropriate.

I suppose Lazarus needs an update, too, as it needs to support the 
upcoming features of the DWARF3 aware debugger.


-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

Graeme Geldenhuys wrote on wo, 11 mrt 2009:

On Wed, Mar 11, 2009 at 4:12 PM, Jonas Maebe   
 wrote:


With DWARF3, this should also be quite doable.


So is DWARF3 only supported in the newest (not really released yet)
GDB?


Yes.


Something like the one that apparently comes with Fedora 11?


The one *will* come with Fedora 11 (it's coming out in June).


I'm currently using GDB that came with Ubuntu 7.10.

[snip]

So I guess I'm all out of luck. :-(
Maybe it's time I update my Ubuntu (though my current one is so nice
and stable).


Even that won't help, since
a) afaik there is not a single distribution out there at this time  
that ships a GDB built from this branch (I think Fedora 11 will be the  
first, which is not really strange considering that it's mostly people  
from Red Hat working on it)
b) even if you select DWARF3, FPC at this time will not generate any  
useful debug information for absolute variables. That needs to be  
fixed first in FPC.


Once FPC is fixed, you can however easily build that gdb yourself. The  
only thing I had to change was to disable treating warnings as errors  
on Mac OS X (presumably because it's a development branch -- but this  
was not necessary on Linux):


./configure --disable-werror
make

and then after a while there was a new gdb at ./gdb/gdb. When I built  
it, some of the necessary DWARF3 stuff was still in a sub-branch  
(they're using git with many people working on different things at the  
same time, so there are branches galore), but everything that's  
necessary has been merged into the main archer branch in the mean time.


See http://sourceware.org/gdb/wiki/ProjectArcher for the checkout  
instructions.


To make FPC generate DWARF3 debug info, use the -gw3 command line  
switch. Note that this is not yet very well tested, and may still  
contain a lot of bugs (with things working with -g and/or -gw2 not  
working with -gw3)



Jonas


This message was sent using IMP, the Internet Messaging Program.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Michael Schnell]

Delphi/Kylix also does not have 'absolute', so FPC requires even more 
features in debugging format also than even K/D.

Not true. (Turbo) Delphi does have "absolute".

-Michael
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Paul Ishenin]

Micha Nelissen wrote:

Graeme Geldenhuys wrote:

And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.

http://opensoft.homeip.net/~graemeg/kylix_debuging.png


Delphi/Kylix also does not have 'absolute', so FPC requires even more 
features in debugging format also than even K/D.

Why have you decided so? I use 'absolute' very often in my delphi projects.

Best regards,
Paul Ishenin.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Micha Nelissen]

Graeme Geldenhuys wrote:

And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.

http://opensoft.homeip.net/~graemeg/kylix_debuging.png


Delphi/Kylix also does not have 'absolute', so FPC requires even more 
features in debugging format also than even K/D.


Micha
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Wed, Mar 11, 2009 at 4:12 PM, Jonas Maebe  wrote:
>
> With DWARF3, this should also be quite doable.


So is DWARF3 only supported in the newest (not really released yet)
GDB? Something like the one that apparently comes with Fedora 11?

I'm currently using GDB that came with Ubuntu 7.10.

grae...@graeme:~$ gdb --version
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu".


So I guess I'm all out of luck. :-(
Maybe it's time I update my Ubuntu (though my current one is so nice
and stable).



Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Wed, Mar 11, 2009 at 3:55 PM, Graeme Geldenhuys
 wrote:
>
>  http://opensoft.homeip.net/~graemeg/gdb_issues_with_fpc.png


And then the same think under Kylix 3. As I said, with Delphi and
Kylix such trivial things is a no-brainer. Debugging just works.

http://opensoft.homeip.net/~graemeg/kylix_debuging.png


Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: Debugger for FPC

[Jonas Maebe]

Graeme Geldenhuys wrote on wo, 11 mrt 2009:


Continuing with the debugging issues on how do I debug something as
simple as the global variable 'ShortDateFormat'? This just shows how
broken debugging is in FPC. With Kylix or Delphi this is a no-brainer!

See the URL below for a screenshot of the issue under Lazarus IDE.  By
the way, I tried 'ddd' which is another GUI frontend for GDB and it
gave the same problem. So once again, it's not a Lazarus issue, but a
flawed GDB and Object Pascal support.


ShortDateFormat is declared as follows:

var
   ShortDateFormat: string absolute DefaultFormatSettings.ShortDateFormat;

FPC simply does not generate any debug information for absolute  
variables at this time.


It may even be quite challenging to generate debug information for  
something like that with Stabs. For DWARF, it seems there is some code  
that generates debug information in some cases, but only for "var a:  
type absolute b;"-style expressions (although I can't even trigger  
that at first sight).


With DWARF3, this should also be quite doable.


Jonas


This message was sent using IMP, the Internet Messaging Program.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Wed, Mar 11, 2009 at 10:24 AM, Graeme Geldenhuys
 wrote:
>
> Simple things that worked in Delphi IDE and even Kylix IDE, but not in
> FPC/Lazarus IDE:
>
> * Breakpoints do not always break
> * Tooltip evaluation of highlighted code gives "no such symbol in
> context" errors
> * Properties on objects cannot be debugged. You have to use the
> underlying field variable if you have access to it, or you the
> property uses access methods you are screwed.
> * In most cases I cannot inspect local variables, due to "no such
> symbol in context" errors
> * debugging nested procedures are totally useless.


Continuing with the debugging issues on how do I debug something as
simple as the global variable 'ShortDateFormat'? This just shows how
broken debugging is in FPC. With Kylix or Delphi this is a no-brainer!

See the URL below for a screenshot of the issue under Lazarus IDE.  By
the way, I tried 'ddd' which is another GUI frontend for GDB and it
gave the same problem. So once again, it's not a Lazarus issue, but a
flawed GDB and Object Pascal support.

  http://opensoft.homeip.net/~graemeg/gdb_issues_with_fpc.png



Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] Re: Debugger for FPC

[Graeme Geldenhuys]

On Wed, Mar 11, 2009 at 10:24 AM, Graeme Geldenhuys
 wrote:
>
> Anybody know what debug format does the Delphi compiler use? I would
> guess they have there own format, for exactly the same reasons I
> mention here.

I did a bit more research and it seems I was on the right track.
Delphi seems to use a customized Microsoft CodeView format which was
extended to support Object Pascal and Delphi language features.

http://www.openwatcom.org/index.php/Debugging_Format_Interoperability


Regards,
  - Graeme -


___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel