[fpc-devel] Debugger for FPC

[Jonas Maebe]

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.

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

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.

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

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.

> 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

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.