[fpc-devel] Debugger for FPC

[Michael Schnell]

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 
procedure ?
> 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 
anyway.
>> * 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 
appropriately ?
> 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.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20090311/4ff1a81f/attachment.html>