[fpc-devel] Debugger for FPC
mschnell at lumino.de
Wed Mar 11 11:23:00 CET 2009
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
> 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 ?
>> * Tooltip evaluation of highlighted code gives "no such symbol in
>> context" errors
> Same can happen in Delphi 7 for example in with statements.
That is why I never use "with" statements. IMHO they ask for ambiguity
>> * 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. :-)
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).
>> * In most cases I cannot inspect local variables, due to "no such
>> symbol in context" errors
> This normally works for me.
Examples for not working code ?
>> * debugging nested procedures are totally useless.
> Switch the stackframe if you want to examine variables of a caller.
Better than Delphi :). Can Lazarus do this, too ? Should it be extended
> 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel