<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Martin Schreiber wrote:<br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<pre wrap=""> ...</pre>
</blockquote>
Martin, I was sure that you would jump in here :) Great !<br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<pre wrap="">
For me GDB with the MSEide frontend is better than the integrated debugger in
Delphi 7. </pre>
</blockquote>
And supposedly better than the Lazarus' one...<br>
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.)<br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<pre wrap="">GDB can switch the stackframe which Delphi 7 cant. </pre>
</blockquote>
This allows for taking a look at the local variable of a ancestor
procedure ?<br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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))". <big></big>Supposedly gdb knows about this.
Maybe this could help handling property functions. <br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
Do you think that issue can be handled ? <br>
<br>
<br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<blockquote type="cite">
<pre wrap="">* Tooltip evaluation of highlighted code gives "no such symbol in
context" errors
</pre>
</blockquote>
<pre wrap=""><!---->
Same can happen in Delphi 7 for example in with statements.
</pre>
</blockquote>
That is why I never use "with" statements. IMHO they ask for ambiguity
anyway. <br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<blockquote type="cite">
<pre wrap="">* Properties on objects cannot be debugged. You have to use the
underlying field variable if you have access to it,
</pre>
</blockquote>
<pre wrap=""><!---->
A small problem once you know it. :-)
</pre>
</blockquote>
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). <br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<blockquote type="cite">
<pre wrap="">* In most cases I cannot inspect local variables, due to "no such
symbol in context" errors
</pre>
</blockquote>
<pre wrap=""><!---->
This normally works for me.
</pre>
</blockquote>
Examples for not working code ? <br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<blockquote type="cite">
<pre wrap="">* debugging nested procedures are totally useless.
</pre>
</blockquote>
<pre wrap=""><!---->Switch the stackframe if you want to examine variables of a caller.
</pre>
</blockquote>
Better than Delphi :). Can Lazarus do this, too ? Should it be extended
appropriately ? <br>
<blockquote cite="mid:200903110959.22688.fpmse@bluewin.ch" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
This argument seems rather striking for me. <br>
<br>
Remote debugging should not be neglected ! We do want to ruin FPC code
on PDAs and embedded systems ! <br>
<br>
Moreover we do want to have additional processors supported by FPC. All
of them of course do already have gdb.<br>
<br>
-Michael<br>
</body>
</html>