Hi everybody,

I'm not sure where is the best place to post this message. If there is a better location, please let me know so I can close this thread and repost in the correct location. Recently there was a discussion about how useless debugging is with FPC and especially inside the Lazarus IDE. It seems that unknowing to most FPC and Lazarus developers, most users tend to use 80's style debugging with FPC. writeln(...) and log files seem to be the norm. I fall under the "log file" users category
- that goodness tiOPF has good logging support and 99% of my projects are tiOPF based.

Anyway, it seems that decent debugger support is a *major* issue with FPC. To be honest, I have no idea how debuggers work, but am willing to learn. If I compare FPC with Delphi - yes I was a Delphi developer for many years but moved over to FPC some 4-5 years ago. Anyway, if I compare FPC to Delphi, the debugger support is *very* lacking compared to Delphi. I am a strong believer that the debugger should be regarded as highly as the compiler. You cannot (or should not) have one without the other!!

About GDB - this seems to be the debugger of choice for the Free Pascal project. It seems GDB was a great stop-gap for the Free Pascal project, but GDB simply doesn't cut in anymore. Support the language features like Properties in Object Pascal are simply non existent. So some things are impossible to debug. GDB is primary designed for C/C++ languages after all.

Like I said, I don't know much about debugger internals - I only know how to use them via a IDE like Lazarus or Delphi. I heard the words "stabs", COFF and DWARF being thrown around. It seems the flavour of the month regarding debug symbol formats is DWARF at the moment. Yet, when I go to the DWARF web site [http://dwarfstd.org/], it describes the format in their introduction paragraph as primarily for C/C++ and Fortan languages.

Quoted from the website:
"It addresses the requirements of a number of procedural languages, such as C, C++, and Fortran, and is designed to be extensible to other languages."

Yes, the say extensible, but I do not see a single reference to Object Pascal on there website or in the DWARF v2 or v3 pdf documents. Yes the do mention "pascal", but as far as I can see it's in the context of ISO Pascal dated back to 1983. Object Pascal has come a looooong way since Pascal of the 80's! So if Free Pascal uses DWARF, surely it can't support all required Object Pascal language features - yet again.

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. Should we rather not design and implement our own Object Pascal debug format that at least supports all our language features. Then build a debugger around that? On notify the DWARF guys there there is a language called Object Pascal and that DWARF spec should be updated accordingly - but who knows how long that route would take.

Just so we are on the same page.... When I talk about the debugger being useless in Lazarus, I don't blame the Lazarus developers, as the issue seems to lie with GDB not supporting Object Pascal very well. Lazarus can only use information supplied by GDB and is thus severely limited by that factor.

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.

For a full list of complaints have a look in the Lazarus mailing list at the thread titled "Debugger problems" with started on 18 Feb. The issues are so important, that a dedicated wiki pages has even been created for it:
http://wiki.lazarus.freepascal.org/GDB_Debugger_Tips

Like I said, I am not very knowledgeable with debugger internals, but I am willing to learn and help. Not having decent debugger support is killing me - and I am clearly not alone, as the thread in the Lazarus mailing list proves. The problem as far as I can see, is that the Free Pascal project is trying to use existing debuggers that were NOT designed to work with the Object Pascal language. So maybe we should stop using those and implement our own debugging symbol format (if that is required) and then continue with writing a debugger specific to Free Pascal. I am more that willing to put in some effort if it means we end up with a working debugger!

Your thoughts?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

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/

On Wednesday 11 March 2009 09:24:53 Graeme Geldenhuys wrote:

For me GDB with the MSEide frontend is better than the integrated debugger in Delphi 7. It is almost impossible to develop something like MSEide+MSEgui with writeln and logfile approach. Manytimes bugs are hard to find in event driven software without watchpoints.
GDB can switch the stackframe which Delphi 7 cant. The problem of the properties is not a big one because of the "f" naming convention, I don't like if gdb would call the getter functions because of possible sideeffects. There are some issues with debuginfo of dynamic arrays in classes, if the FPC team is interested, I can try to build testcases to show the problems.

Hi everybody,

[...]

I never seen this in MSEide.

* Tooltip evaluation of highlighted code gives "no such symbol in context" errors

Same can happen in Delphi 7 for example in with statements.

* Properties on objects cannot be debugged. You have to use the underlying field variable if you have access to it,

A small problem once you know it. :-)

or you the property uses access methods you are screwed.

Think on the possible sideeffects.

* In most cases I cannot inspect local variables, due to "no such symbol in context" errors

This normally works for me.

* debugging nested procedures are totally useless.

Switch the stackframe if you want to examine variables of a caller.

[...]

Using gdb has the *big* advantage to have a working environment on many platforms with working remote debugging. I suspect the work for developping an own debugger will be very big, have a look into the gdb sources and you know what I mean...
The main problem with gdb is the communication by pipes and the not finished mi-interface, once the communication works and the workarounds for the missing mi-functions are done gdb is not bad.

Martin

You might want to take a look at the great book by Maltiff & Salzmann: "The Art of Debugging". They provide a very nice overview about what gdb can do. They also describe the gdb frontends DDD and Eclipse Of course they only use C as a programming language.

They say that using a debugger has a lot advantages over code instrumentation.

Nonetheless, Delphi, besides a relatively decently working realtime Debugger, provides additional service for code instrumentation with dedicated function ( "OutputDebugString()" ) and a additional "trace" debug window. (I don't know whether Lararus offers this, too.)

Lazarus is just another frontent for gdb, so in theory anything that gdb offers should work decently through Lazarus. And IMHO, Lazarus is a really nice gdb frontent (if it would work perfectly).

-Michael

Florian Klaempfl wrote

GDB is ported for >10 years to windows and it's behaviour is still *very* poor.

MinGW gdb 6.8-3 works well for me.
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507&release_id=594520

Martin

Michael Schnell wrote

You might want to take a look at the great book by Maltiff & Salzmann: "The Art of Debugging".

That's, I'll go to Amazon and see what it's about....

They also describe the gdb frontends DDD and Eclipse Of course they only use C as a programming language.

Of course they only use C (no surprise) - no other programming language exists. ;-)

Lazarus is just another frontent for gdb, so in theory anything that gdb offers should work decently through Lazarus.

That's the problem! GDB *doesn't* support all the language features that Object Pascal offers, so some things cannot be debugged. This is not a Lazarus issue, but a limitation of GDB with the Object Pascal language. And I have heard the comments about trying to implement new features in GDB - apparently you do NOT want to go there!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hello Graeme,

I fully agree with this. Not having acceptable debugging is the only reason stopping me from recommending adopting Lazarus at work. The development time penalty is simple too high to justify.

I don't know whether I could find time to help, maybe at weekends at home, I certainly ,
Dave

Are you aware of the fact that Marc already started a debugger? It's somewhere in the lazarus repository. It uses dwarf as debugging information. dwarf is good enough for most object pascal constructs, if it is missing someting, it can be probably extended (I wrote the dwarf generator for FPC). I'am also willing to invest some time in a debugger written in pascal because the text mode ide has to get rid of libgdb because it is deprecated. Using the command line interface to integrate gdb into the ide is imo no option: it is slow and I never saw a good gdb gui front end.

Of course they only use C (no surprise) - no other programming language exists. ;-)

In fact they do have a section about Java, Perl, Python, and Assembler at the end of the book :).

-Michael

Finally getting rid of GDB: This is VERY good news indeed :-)

Michael.

Florian Klaempfl wrote

Are you aware of the fact that Marc already started a debugger?

Now that you mention it, I vaguely remember something like that mentioned. I think it was only for Windows, but I'll hunt it down and see if we can use that as a starting block. Thanks for mentioning it.

it is missing someting, it can be probably extended (I wrote the dwarf generator for FPC). I'am also willing to invest some time in a debugger written in pascal because the text mode ide has to get rid of libgdb

To to hear that you are also interested in a new debugger, means I have not totally lost the plot. :-) I was no desperate at one point with debugging, I tried the text mode ide as well, but I couldn't even get debugging support compiled in. :-( Plus having a debugger written in pascal will simply be the cherry on the cake.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Finally getting rid of GDB: This is VERY good news indeed :-)

it's been getting rid of GDB for some time already... but, imho it should not be removed!

1) because GDB supports a lot of platforms, already. So porting a fpc program to a new platform, will require a debugger. And the only debugger available will probably be gdb.

2) gdb can be extended to support FPC syntax, if enougth information is provided with GDB. And ofcouse, some C-po

I vaguely remember something like that mentioned. I think it was only for Windows,

debugger can be found at: {$lazdir}/debugger/fpdebug i've already started fp-debugger developing (personally i need it for OSX), and helped Marc to remove some Windows-only bounds. Well, maybe it's better to remove fpdebugger from Lazarus to a stand-alone project.

thanks,
Dmitry

sorry! unfinished note:
2) gdb can be extended to support FPC syntax, if enougth information is provided with GDB. And ofcause, some C-programmer might be required.

GDB is ported for >10 years to windows and it's behaviour is still *very* poor.

Yes; if it materializes this time, that's it... ;-)

Some time ago I asked Allan Mertner about possibility of getting access to the Virtual Pascal debugging support source code. Obviously, this wouldn't help with the debugging format support, because VP used a proprietary debug symbols format, but it would be probably useful for platform integration (remember that this stuff is rather low-level and completely platform specific!) - and VP supported debugging under all of OS/2, Win32, Linux and DOS (using a different DPMI extender, but nevertheless)! If there is a real working group seriously working with this, we may still try to convince Allan to provide access to this code. I'm personally interested and would be willing to try helping with the OS/2 part, but I certainly don't have capacity for anything more...

Tomas

He gave his Debugging support to the Morfik people, so I don't see why he could not give it to us...

Michael.

GDB is ported for >10 years to windows and it's behaviour is still *very* poor.

but at least, it works.
Is there any other debugger that can be used cross-platform, rather than gdb?

yes, there should be fpc based debugger, but gdb support should not be removed, either.

dmitry boyarintsev wrote

> Finally getting rid of GDB: This is VERY good news indeed :-)

I quite agree !

Not really, there is low-level debugging support inside the OS. This is true for Windows as well as for UNIX-like operating systems.

Regards,

Adriaan van Os

dmitry boyarintsev wrote

sorry! unfinished note: 2) gdb can be extended to support FPC syntax, if enougth information is provided with GDB. And ofcause, some C-programmer might be required.

I'm not really sure about this. IIRC the internal design of gdb is modeled after the STABS debug format. This means that even for DWARF, it internally is translated to STABS, meaning that not all contstucts possible in DWARF are supported. Given this I have doubts that all features of FPC can be implemented in gdb. (again, IIRC)

Marc

Graeme Geldenhuys wrote on wo, 11 mrt 2009:

About GDB - this seems to be the debugger of choice for the Free Pascal project.

It is the only debugger I know of that supports pretty much every single platform out there. In fact, there are simply very few other free (even as in beer) debuggers out there, if any.

GDB is designed for any language it has maintainers for (just like FPC is "designed" for all platforms that have active maintainers, and languishes or is non-existent on others). For example, GDB also has excellent ADA support (which is a godsent, because many ADA things can be reused for Pascal, e.g., the support for set types in DWARF was implemented by the ADA guys and we later just activated it for Pascal as well).

Like I said, I don't know much about debugger internals - I only know how to use them via a IDE like Lazarus or Delphi. I heard the words "stabs", COFF and DWARF being thrown around. It seems the flavour of the month regarding debug symbol formats is DWARF at the moment.

DWARF is much more than the "flavour of the month". It's a very generic debug format, which is also specifically defined as vendor-extensible.

Yes, the say extensible, but I do not see a single reference to Object Pascal on there website or in the DWARF v2 or v3 pdf documents.

That is not what extensible means.

It can.

Then build a debugger around that? On notify the DWARF guys there there is a language called Object Pascal and that DWARF spec should be updated accordingly - but who knows how long that route would take.

That is not necessary. The DWARF3 spec even contains the following paragraph right near the start:

***
1.3 Vendor Extensibility

This document does not attempt to cover all interesting languages or even to cover all of the interesting debugging information needs for its primary target languages (C, C++, Fortran, Modula2, and Pascal). Therefore, the document provides vendors a way to define their own debugging information tags, attributes, base type encodings, location operations, language names, calling conventions and call frame instructions by reserving a portion of the name space and valid values for these constructs for vendor specific additions. Vendors may also use debugging information entries and attributes defined here in new situations. Future versions of this document will not use names or values reserved for vendor specific additions. All names and values not reserved for vendor additions, however, are reserved for future versions of this document.

DWARF Version 3 is intended to be permissive rather than prescriptive. Where this specification provides a means for describing the source language, implementors are expected to adhere to that specification. For language features that are not supported, implementors may use existing attributes in novel ways or add vendor-defined attributes. Implementors who make extensions are strongly encouraged to design them to be backward compatible with this specification in the absence of those extensions.
***

Just so we are on the same page.... When I talk about the debugger being useless in Lazarus, I don't blame the Lazarus developers, as the issue seems to lie with GDB not supporting Object Pascal very well.

This is correct, although it's not because the GDB guys hate or don't care about Pascal. In fact, they are always very welcoming and helpful when someone submits a patch for any language (in correcting errors/making it compliant with GDB coding standards & conventions). And we still have Pierre Müller (who used to work on FPC) as designated maintainer for Pascal support in GDB. He does not have much time to work on it, but is generally quite quick to apply submitted patches.

That said, GDB is not the nicest code base to work on. But I at least do not intend to maintain a debugger code base for Mac OS X, its 5 architectures (it will become 3 once PPC is completely gone, but who knows what's next), its extensions to its object format every 5 major revisions, its three kinds of dynamic libraries, etc. Getting familiar enough with the GDB source base was a lot less work for me than that would entail (and if you also submit test cases to GDB, its regular maintainers will ensure that nothing you add will break in the future).

Not to mention that in many real world projects (at least on Mac OS X), a debugger is pretty useless if it does not also support C, C++ and Objective-C (there's a lot of mixed language development on Mac OS X).

Simple things that worked in Delphi IDE and even Kylix IDE, but not in FPC/Lazarus IDE: * Breakpoints do not always break

This is probably caused by errors in FPC's debug information, if you have a reproducible case.

If it just happens sporadically (or only in Lazarus), it may be an error in the debugger state maintained by Lazarus. I have seen such non-reproducible cases back in the days in the textmode IDE every now and then, but never with command line gdb.

* Tooltip evaluation of highlighted code gives "no such symbol in context" errors

The reason for this probably depends on the kind of symbol: a) variable of a parent procedure in nested procedure: missing gdb support (although in combination with Lazarus' code tools, Lazarus' debugger could probably activate the correct frame and print it there) b) property: no support in gdb
c) bugs in the tooltip feature? (does it work if you try to get the value in another way?)

* 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.

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.

* In most cases I cannot inspect local variables, due to "no such symbol in context" errors

I've never seen this (at least not in command line gdb; I've never used Lazarus to debug), except for the nested variables case, or if you compiled with register variables enabled.

* debugging nested procedures are totally useless.

Partially true, see above.

At least the "Variables treated as pointer" and "Dynamic Arrays" can be completely solved with plain DWARF3 (as supported by the gdb that will be shipped with Fedora Core 11, and hopefully by other distributions/platforms soon as well). For the dynamic arrays support, someone from Red Hat even fixed a bug in GDB's DWARF handling that only manifested itself with FPC-generated debug info on Mac OS X (just to demonstrate how willing these people are to help).

Actually, the nested variables case can probably also be solved using DWARF3 (we can automatically load the parent frame pointers in DWARF3 expressions).

And of course "Also remember that it would be dangerous to call the function from the debugger (outside the normal flow of the application). This can modify the state of the application (a function may change other objects)" cannot be solved by any debugger (even if you'd take a complete snapshot to restore afterwards or did that in a forked version of the process, I/O related things could still change the state in a non-reversible/sandboxed way).

The problem as far as I can see, is that the Free Pascal project is trying to use existing debuggers that were NOT designed to work with the Object Pascal language.

The problem is that nobody except for Pierre ever seriously invested in creating a versatile Pascal debugger, regardless of whether it was based on GDB or designed from scratch.

You can of course create a new debugger. The advantage compared to GDB would obviously be that it'd be written in Pascal and would have a more modern code base. The downside would be that it would probably not support all of FPC's platforms, so much of the work will have to be duplicated in GDB anyway. And as mentioned before, you may have to add debugging support for other languages too.

It would also be another major project that'd need developing and maintaining by the same crowd (unless you'd find a completely new bunch of people that currently does not work on FPC and/or Lazarus to work on this debugger).

Jonas

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

Martin Schreiber wrote

...

Martin, I was sure that you would jump in here :) Great !

For me GDB with the MSEide frontend is better than the integrated debugger in Delphi 7.

And supposedly better than the Lazarus' one...
Could you take a look at the Wiki page mentioned and comment on if the issues mentioned there are taken care of with MSEGUI. (I do know that MSEGUI can show an ASM window, that Lazarus recently could not.)

GDB can switch the stackframe which Delphi 7 cant.

This allows for taking a look at the local variable of a ancestor procedure ?

The problem of the properties is not a big one because of the "f" naming convention, I don't like if gdb would call the getter functions because of possible sideeffects.

I wonder how Delphi manages this. It seems some property functions are evaluated by debugger, some are not. I do know that GCC has a specification for functions that don't have side effects ("__pure", "__attribute__((pure))". Supposedly gdb knows about this. Maybe this could help handling property functions.

There are some issues with debuginfo of dynamic arrays in classes, if the FPC team is interested, I can try to build testcases to show the problems.

Do you think that issue can be handled ?

That is why I never use "with" statements. IMHO they ask for ambiguity anyway.

It _should_ work anyway: both if there is an read "f" variable, and if the read function is "pure". If there is no read and if the read function has side effects there of course is no chance at all (by design of the language).

Examples for not working code ?

Better than Delphi :). Can Lazarus do this, too ? Should it be extended appropriately ?

This argument seems rather striking for me.

Remote debugging should not be neglected ! We do want to ruin FPC code on PDAs and embedded systems !

Moreover we do want to have additional processors supported by FPC. All of them of course do already have gdb.

-Michael

>> Finally getting rid of GDB: This is VERY good news indeed :-) I quite agree !

it was not my words :)

Not really, there is low-level debugging support inside the OS. This is true for Windows as well as for UNIX-like operating systems.

gdb is always based on system debugging API (DebugAPI in Windows, ptrace for BSD and Linux, machAPI for OSX).

one can think of gdb as a wrapper over system API. :)

My main problem (if they really work) with all gdb gui frontends is that they are dog slow compared with a good debugger like Visual Studio.

Martin Schreiber wrote

For me GDB with the MSEide frontend is better than the integrated debugger in Delphi 7.

I can't comment on GDB+MSEide, but for me and many others Delphi debugger is *much* better that GDB+Lazarus.

It is almost impossible to develop something like MSEide+MSEgui with writeln and logfile approach. Manytimes bugs are hard to find in event driven software without watchpoints.

Then try and debug tiOPF's visitors! :-) Anybody using hard-coded visitors with tiOPF will know what I mean. I have learnt to master the log file approach.

> * Tooltip evaluation of highlighted code gives "no such symbol in > context" errors Same can happen in Delphi 7 for example in with statements.

In Delphi 7 it only happened in with statements. In Lazarus it's more frequent, even outside with statements.

Everybody keeps hammering on this point. Delphi has supported property access methods since forever and I have not heard of a single Delphi developer complaining about the "possible side effects". For me the pros far outweigh the cons!

Using gdb has the *big* advantage to have a working environment on many platforms with working remote debugging. I suspect the work for developping an own debugger will be very big, have a look into the gdb sources and you know what I mean...

Well writing a new compiler is just such a big task and it didn't prevent Florian from starting FPC. Having a 100% working debugger (no matter if it takes a while to get there) is still much better in the long run - for the developers and for the Free Pascal Compiler project. Not to mention MSEide and Lazarus IDE could benefit from it too.

The main problem with gdb is the communication by pipes and the not finished mi-interface, once the communication works and the workarounds for the missing mi-functions are done gdb is not bad.

Well at least having our own object pascal based compiler, we will be able to implement new features and fixes much quicker than GDB.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Michael Schnell wrote

> Switch the stackframe if you want to examine variables of a caller. > Better than Delphi :). Can Lazarus do this, too ? Should it be extended appropriately ?

Lazarus can.

Best regards,
Paul Ishenin.

Florian Klaempfl wrote

My main problem (if they really work) with all gdb gui frontends is that they are dog slow compared with a good debugger like Visual Studio.

Agreed. MSEide has a button to disable the watches for fast stepping. On a modern computer gdb with MSEide frontend is fast enough for me. Another nice gdb feature is the ability to debug C-libraries linked into a Pascal program.

Martin

I think it would be better to extend gdb for better FPC support.

Martin

Yes, don't forget to compile with -O-.
[...]

Yes.

Jonas Maebe wrote

GDB is designed for any language it has maintainers for (just like FPC is "designed" for all platforms that have active maintainers, and languishes or

Probably true, but it's leans a lot more to C/C++ support than any other language.

DWARF is much more than the "flavour of the month". It's a very generic debug format, which is also specifically defined as vendor-extensible.

I downloaded the latest DWARF3 spec - last updated in December 2005. Quite a while back. Is this good or bad? Or is the DWARF3 spec so good/flexible it caters for any new language features since 2005?

This is correct, although it's not because the GDB guys hate or don't care about Pascal. In fact, they are always very welcoming and helpful when someone submits a patch for any language (in correcting errors/making it

Umm, and that means I have to go back and study C language again. I left C/C++ for a reason. Object Pascal is a much better language in my eyes, and I'm a lot more productive with the latter as well!

Not to mention that in many real world projects (at least on Mac OS X), a debugger is pretty useless if it does not also support C, C++ and Objective-C (there's a lot of mixed language development on Mac OS X).

Well, I only work with the Free Pascal Compiler (and occasionally dab in Java). This issue I am raising relates directly to Free Pascal Compiler and the Object Pascal language, so I don't give a toss about any other languages or supporting them. After all, they have GDB. ;-)

> * Tooltip evaluation of highlighted code gives "no such symbol in > context" errors

...

c) bugs in the tooltip feature? (does it work if you try to get the value in another way?)

It always works if I use log files. :-)

Again, I never heard a single Delphi developer complain about debugging properties with or without accessor methods. So what did Borland do different?

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Martin Schreiber wrote

I think it would be better to extend gdb for better FPC support.

I don't see myself relearning C language again! I left C/C++ for a reason.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Here the "pure" attribute That gdb/DWARF should be aware of might help. Of course FPC would need to set this attribute automatically if the function in fact is "pure".

-Michael

dmitry boyarintsev wrote

debugger can be found at: {$lazdir}/debugger/fpdebug i've already started fp-debugger developing (personally i need it for OSX), and helped Marc to remove some Windows-only bounds.

Well, I guess you guys didn't get very far with removing Windows only requirements. The very first unit fpd.lpr contains a "Windows" unit in the uses clause. :-( So I couldn't compile it under Linux. I will study the code though.

Well, maybe it's better to remove fpdebugger from Lazarus to a stand-alone project.

In the end this will probably be a good idea. Maybe making it a sub-project of FPC.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I suppose thy to check if a read function is "pure". I seem to remember that there are property values you can't in the debugger, so there seems to be some kind of classification.

-Michael

I don't see myself relearning C language again! I left C/C++ for a reason.

Where is the problem with C ? Of course it's by far less "nice" than Object-Pascal, but I don't suppose with doing a Debugger the "Object" feature does not help that much, and for low-level stuff C seems quite appropriate (I'm not saying Pascal is not !).

-Michael

O/H Dave Parsons έγραψε:

Graeme/All Hi,

if you or someone start a debugger written in object pascal count me in also. I'll find the time to learn and help.

regards,

Graeme Geldenhuys wrote on wo, 11 mrt 2009:

It supports ADA at least as well. In fact, it probably supports ADA better than C++ (although C++ support got a big overhaul the new gdb based on the Archer branch in Fedora Core 11, so it may finally get up to speed).

Neither. They are working on DWARF4 though, if that's what you mean. See here for a number of reported and resolved issues in that version: http://www.dwarfstd.org/Issues.php?type=closed3

Or is the DWARF3 spec so good/flexible it caters for any new language features since 2005?

I don't know of a single Object Pascal developer ever proposing new extensions to be incorporated into the DWARF standard.

Me too. But I'm also more productive when submitting a few patches and bug reports against gdb every now and then, than when completely rewriting and maintaining a debugger clone (even if written in the cleanest Object Pascal in the world) on at least 5 platforms.

That's useless when people combine Pascal and C code in a single program. And you may not do that, but I'm not developing FPC only for you.

> c) bugs in the tooltip feature? (does it work if you try to get the value in > another way?) It always works if I use log files. :-)

I meant using the debugger, obviously.

Jonas

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

Marc Weustink wrote on wo, 11 mrt 2009:

Just like FPC development, GDB development does not stand still. The above no longer is true (full, or nearly full, DWARF3 support is in the GDB Archer branch, and I have already fixed bugs in FPC's DWARF3 information so that e.g. dynamic arrays work perfectly in that version of GDB).

Jonas

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

Is there any windows binary exists compiled from this branch which we can take and test?

Best regards,
Paul Ishenin.

Paul Ishenin wrote on wo, 11 mrt 2009:

I don't think there are currently any compiled binaries for any platform, as it's still very much under development. I compiled it successfully from source for Linux/i386 and Mac OS X/i386 (somebody apparently started adding Mac OS X/i386 support to regular GDB, although it's still a bit flakey here and there). I don't know how well/badly it builds for Windows though, or even how easy/difficult it is in general to build GDB for Windows.

Jonas

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

Graeme Geldenhuys wrote

Like I said, I am not very knowledgeable with debugger internals, but I am willing to learn and help. Not having decent debugger support is killing me - and I am clearly not alone, as the thread in the Lazarus

The problem is not so much the debugging itself. That is easy. (In linux e.g., couple of lines using ptrace). Most of the work is reading debug symbols and all the various execution formats of various platforms.

Micha

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/

Graeme Geldenhuys wrote on wo, 11 mrt 2009:

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.

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/

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.

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/

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

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

Best regards,
Paul Ishenin.

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

Graeme Geldenhuys wrote on wo, 11 mrt 2009:

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.

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

Michael Schnell wrote on wo, 11 mrt 2009:

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.

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

I agree. The current ways to debug FPC/Lazarus programs are not up to the standards even compared to 10-15 years ago Delphi debugging.

Most developers does not want to start digging the underlying RTL/Component, etc. source codes to figure out what they should enter into the watch window expression instead of the variable name they are trying to see. They want to focus on developing what they are working on. They want - rightfully - to double click or copy paste or mouse-over to see the variables, properties, etc.
If they need to learn a translation dictionary to do (hack) it - if at all it is possible to see that variable - then it is not acceptable and significantly slows the development. Not to mention to change variable values, re-executing/jumping to parts of the code (New CS:IP), CPU window, etc.

This is one of the major things that is missing from FPC/Lazarus at the moment (for many people the most important).
No matter how awesomely FPC and Lazarus progresses this will be always a show stopper for the majority of developers until it is resolved. Whether it is GDB, native FPC debugger, or something else, it does not matter as far as it does the job in a satisfactory manner. Currently, it does not.

AB

Graeme Geldenhuys wrote

Hi everybody,

.
. SNIP
.

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/

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

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/

Op Thu, 12 Mar 2009, schreef Vincent Snijders:

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

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.

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.

Who volunteers to create it?

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

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.

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/

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

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

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

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

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?

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.

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

Jonas

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?

Ok.

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

> 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

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

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

Michael.

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

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.

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

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
<http://gnu.org/licenses/gpl.html>
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.

Keeping -gl instead of -gw?

Tomas

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

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.

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

Jonas

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.

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

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

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.

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.

Hello,

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

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/

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.

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

Best regards,
Paul Ishenin.

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

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

-Michael

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.

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

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