#9 Fixed more debugging bugs

[ricky cancro]

In this update I fixed a couple of things:

1) Some of the fixes I made on the first pass with the
debugger were not added to the source (it was my fault,
I didn't mark the change with my initials, and didn't
send a diff file). I wanted to make sure these changes
got added (otherwise the changes I made the first time
wouldn't work)

2) Occasionally when debugging, I would get this error:
Dev-C++ would stop on a break point
I'd click the step button -- nothing would happen
I'd click the step button again -- the cursor would
jump two lines instead of one.
I fixed this by making changes to debugreader.pas

3) There are times, where debugging a GUI program that
uses a DLL, that the debugger steps into the DLL but
there is no source file available to step through. In
this case GDB would have a valid frame, but no valid
source file. In Dev-C++ the cursor would stay at the
bottom of the last executed function until the user
clicks continue. This could cause the following problem:
The cursor is at the end of a function
The user presses next a couple of times
The cursor in Dev-C++ is still at the end of the
function, but GDB is no longer broken.
The user presses continue in Dev-C++ to start the
program back up.
The program hits a breakpoint
All of the continues that the user clicked when Dev-C++
was at the end of a function but GDB was not get
applied at the new breakpoint (that is, the breakpoint
is hit and then the cursor automatically performs
"step" the number of times the user hit the cursor once
GDB had returned)
I added a function called inaccessible function to make
sure that when the debugger goes into a DLL or library
with no source file, dev-cpp seend a continue command

4) Related to 3 -- pressing next when the debugger is
not broken will cause the debugger to automatically
move forward that many steps when it does reach a break
point. This problem also exists in the command line
version of GDB. For example:
start a program in gdb.
On the gdb console type 'n' X number of times
Make the program being debugged hit a break point
GDB hits the break point and then moves ahead X steps
I changed the code to look to see if the debugger is
broken before sending a command to it. This fixes the
problem

5) The biggest change I made had to do with breakpoints
in files that are closed. In the most recent version
of Dev-C++ the following would happen:
Open a file and add a break point
Start the debugger
Before your code reaches the breakpoint, close the file
with the breakpoint
When GDB reaches the breakpoint the file that you
closed will automatically be reopened and the cursor
will be at the place where the breakpoint should be
However, closing killed that file's editor object and
therefore removed all of its breakpoints.
Now Dev-C++ and GDB are in inconsistent states -- GDB
thinks there is a breakpoint while Dev-C++ does not

To fix this I created 1 global list of breakpoints that
is not editor dependent. I removed the breakpoint list
in editor and debugger and added one to main. Closing
a file no longer removes the breakpoint from the file.

[ricky cancro]

Diff and new source of debugger.pas, debugwait.pas, debugreader.pas, editor.pas, main.pas

[Colin Laplace]

Logged In: YES
user_id=25510

Thank you, the patch has been applied

Greetings,
Colin