[fpc-devel] Debugger for FPC
graemeg.lists at gmail.com
Wed Mar 11 11:54:05 CET 2009
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
> 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
Again, I never heard a single Delphi developer complain about
debugging properties with or without accessor methods. So what did
Borland do different?
- Graeme -
fpGUI - a cross-platform Free Pascal GUI toolkit
More information about the fpc-devel