Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Splitting debugger in two - specific debugger and common GUI

<< < (86/136) > >>

oBFusCATed:
1. Yes
2. GetBreakpoint is the old not added by me, GetStackFrame is added by me I think. Probably they should be made to match
3. return 0 in GetThreadsCount() and GetThread won't be called, you can return return cbThread(), so it will crash if it is called and we could fix, such places
4. It is left to the debugger plugin implementation to decide, what to there, if you feel we need to add default implementation say so
5. Manager::Get()->GetDebuggerManager()->GetWatchesDialog()->UpdateWatches();
6. It is common for all of them.

It you feel we should use pointers everywhere in the GetSomething API, please say so, I'll make a patch... My style/desire is to use references whenever is possible, but looking at it now probably pointers are better here.

dmoore:

--- Quote from: oBFusCATed on February 11, 2011, 08:00:52 pm ---It you feel we should use pointers everywhere in the GetSomething API, please say so, I'll make a patch... My style/desire is to use references whenever is possible, but looking at it now probably pointers are better here.

--- End quote ---

Well I'm not sure either way, but I'd like to do it the same way for Breakpoints/Threads/Watches/CallStack. The slight advantage of the reference is that the caller knows they don't have to delete it. The advantage of returning pointers is that this is far more pervasive in C::B and wxWidgets.

Almost done with a rough version of the Python Debugger. The last major job is to implementing watches, which, admittedly looks rather time consuming ... After that I'll refactor the code and make the interface to pdb a separate class, then implement a class that interfaces with rpdb2, a more suitable python debugger for doing I/O redirection.

dmoore:
3 bugs (not ruling out that it is something I have done wrong):

1. After compiling and running the branch + PyDebugger plugin on WinXP, the PyDebugger appeared first on the "Debug -> Active Debuggers" menu. The radio checkbox got stuck on "debugger gdb", but the python debugger was active. It was impossible to reactivate debugger gdb.

2. Breakpoints:
* GDB debugger is active
* Set breakpoints
* Now make python debugger active: the set break points are not activated in the python debugger, but still display in editor.
SUGGESTED FIX: The framework should sync the editor to the breakpoints of the active debugger after switching.

3. Crash after disabling/uninstalling debuggergdb plugin

dmoore:
Also, find I'm exactly copying the watch class implementation of gdb_mi. Move to SDK? (i.e. rename current cbWatch as cbWatchBase, and cbWatch becomes the implementation in gdb_mi)

oBFusCATed:

--- Quote from: dmoore on February 16, 2011, 05:22:07 am ---Also, find I'm exactly copying the watch class implementation of gdb_mi. Move to SDK? (i.e. rename current cbWatch as cbWatchBase, and cbWatch becomes the implementation in gdb_mi)

--- End quote ---
If you're sure you won't need anything else it won't be a problem.
But I don't like cbWatchBase, cbWatchSimple is better name for the gdb_mi::Watch?

What do I need to install in order to test your py debugger?

Navigation

[0] Message Index

[#] Next page

[*] Previous page