Splitting debugger in two - specific debugger and common GUI

[oBFusCATed]

In the case for GDB I use them only for internal memory management I think. I don't want to bother with calling
"for each(it in breakpoints) delete *it;". I think this is the only purpose of the shared_ptr here.

[dmoore]

In the case for GDB I use them only for internal memory management I think. I don't want to bother with calling
"for each(it in breakpoints) delete *it;". I think this is the only purpose of the shared_ptr here.

Wasn't sure if you were worried about the plugin deleting cbBreakpoint instances while the framework was still using them. I notice that I don't have the tr1 stuff in my current MinGW isntall, which is maybe a small argument for not using shared_ptr. If the framework provides the breakpoint container and manages all of the "delete *it" etc, then probably not a big deal to just use regular pointers... (hides in corner from C++ faithful).

[oBFusCATed]

You're using gcc/g++ < 4?
How did you manage to compile the branch, it uses shared_ptr extensively?

[dmoore]

You're using gcc/g++ < 4?
How did you manage to compile the branch, it uses shared_ptr extensively?

Well I didn't on this machine, but I have more than one machine (and regularly use both linux and windows). I guess I'm a bit out of date on this windows box.  :?

[dmoore]

More questions...

1/ It looks like providing editor tooltips (to instantly "watch" a value) is left completely to the plugin at the moment. Is that right?
2/ Why is const cbStackFrame& GetStackFrame(...) ok, but const cbBreakpoint& GetBreakpoint(...) not? (pointer vs reference consistency issue)
3/ If a debugger doesn't support threads, what should "const cbThread& GetThread(...)" return? Should there be default implementations that do nothing for those?
4/ Likewise, are AttachToProcess, DetachFromProcess, IsAttachedToProcess optional and if so, shouldn't they have default implemetations?
5/ How should a Debugger signal the framework to update the watch and call frame?
6/ Does each debugger use its own debugger log or do they all share one?

[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]

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.

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]

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)

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?

[dmoore]

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

Other than what you normally need: Python and a script to debug. On windows, I think you need to put python in your path (but you can point to the location of python interpreter in settings->environment->PyDebugger). You might also need to tweak the project build settings.

[oBFusCATed]

I'm on linux, so python is runnable...

p.s. The configuration for PyDBG should not be there
p.p.s. Settings -> Editor and Settings -> Environment are too confusing already, I always have to open both to find the option I'm looking for

[dmoore]

I'm on linux, so python is runnable...

you should be good to go then.

p.s. The configuration for PyDBG should not be there
p.p.s. Settings -> Editor and Settings -> Environment are too confusing already, I always have to open both to find the option I'm looking for

Agree, I adapted the code from an old python plugin, which explains all of the cruft. Where are global debugger settings supposed to go?

[oBFusCATed]

In Compiler & Debugger, but I'm not sure how it is handled at the moment

[Pecan]

RE: SVN 6973

"Run to cursor" (to start the debugger session) works. It stops at the cursor position.

"Step Into" does not. It run the complete program without stopping.