[fpc-devel] Debugger for FPC

[Graeme Geldenhuys]

On Wed, Mar 11, 2009 at 12:20 PM, Jonas Maebe <jonas.maebe at elis.ugent.be> 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. :-)



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

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/