basically I would like a more effective management of the breakpoints, and specifically the possibility to break the running program, this works but not always.
Breaking the debuggee isn't trivial. The most reliable way I have found is to use CreateRemoteThread() and use DebugBreak() as the function to execute. On XP this can be simplified to DebugBreakProcess(). The process usually stops OK (Win 95/98/Me might as usual be more problematic). This means the process will be stopped in DebugBreak().
The only other way I could do this, is to single-step the processor, and look for a break request after every assembler instruction in the debuggee. Would work great, except it would take "forever".
All project breakpoints will be listed on a separate tab in v4.0, where you can disable them, or change conditions (pass-count etc.).
Moreover the dynamic setting of breakpoints isn't very effective, many times adding a breakpoint while the process is running give no guarantee that it will be executed (still a big mess when you are following a random bug), so you don't know if execution is not tracing that part or you are simply missing the break. Eventually if you restart the debbugging happen to receive an error advice about the impossibility to set a previously issued breakpoint.
You can't add breakpoints while the process is running! You can toggle breakpoints in a source code window while debugging, but this doesn't help, since breakpoints are only moved to the debugger when it's started. In v4.0 you will only be able to toggle breakpoints in the debugger window (and as before, only when the process is paused).
Setting breakpoints in a source code window is unfortunately not an exact science. I don't know which lines will actually generate code, so I accept breakpoints everywhere. The debugger will only see source lines with some code attached - if it finds a breakpoint on some other line, it will complain. (Moving such breakpoints to the closest line might not always be a good idea because of "hidden" jumps, which will change the meaning).
Now my wishes list:
- A tracing option to run out of a function (in case of you enter the debug of a big loop or any kind of time consuming code)
I have added this, but limited to the following:
a) You must be stepping out of a C function
with debugging info (MASM code won't work).
b) The function must use, or be in the process of using, an EBP stack frame (should be OK for Pelles C compiled code, since the compiler will always produce EBP stack frames when debugging info is ON).
If the following conditions are met, I can read the return address from the stack and set a special (internal) breakpoint there.
- A tracing option to run up to the cursor
OK - easy to add. I find it useless myself, but why not?
- To choose the visualization format for the memory (byte, word, dword, float,...., or event data formats structs etc)
Since you can also edit the memory, viewing it in other formats seems confusing to me. Maybe in the future through some add-in support.
- To display memory at register address (specify EAX, EDX, ESI....)
The address can be an expression in v4.0, and an expression can reference CPU registers, so this will work.
- When breaking the execution if it is outside our code to have an assembler view of instructions instead of blank screen
If the debugger is paused, and I am allowed to read from the current address, AFAIK you should see at least assembly code...(?)
- A dialog for breakpoints management that permits to change, set, reset breakpoints, even showing the list of the available functions to wich a break is applicable (same database of project symbols)
Breakpoint tab in v4.0. The project tree can be used. When the debugger window have focus, and you double-click on a function in the project tree, it should jump to that function (provided it's part of the debugging info).
Pelle consider that when you start a debbugging session is always when you are in a high stress phase for a bug that is not easily deduced by logical discerning, and generally late at night......
Mmm. Briefly. ;-)
I don't think any software can handle this scenario gracefully... :-)
Pelle
