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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
