Splitting debugger in two - specific debugger and common GUI

[oBFusCATed]

I don't need to compile it, in order to tell you that they are unused, at least in 5d.patch (tested with compiling, too)
Probably you have something different in you working copy.

Also, what do I need to do to reproduce the case, that requires the introdution of GdbCmd_ChangeFrame?

[cbexaminr]

include missed gdb_driver.cpp which invoked the descendant classes.

[cbexaminr]

Also, what do I need to do to reproduce the case, that requires the introdution of GdbCmd_ChangeFrame?

umm, umm, umm....

I can't remember precisely.  It has to do with stepping into code that you don't have a stack frame for, or don't have source information for, or perhaps either.  (I think it usually involved stepping into runtime library and or OS areas, although not all of them.)  The frame N command output was being trapped by the breakpoint stuff in that ParseOutput() routine, and resulted in a (re-)disassembly to a position that matched the source code ("first position found with matching source code" - autoswitch), rather than where the program was actually going to step next.  I was unable to find (doesn't mean there isn't one) a [edit]_reliable_[/edit] way to determine _what_ the next process instruction address was - the info frame and bt commands did not seem to always provide correct information, for certain frame(-less) situations.

I have been using the early tooltip demo program, breaking at the "if(bFirstTime)" line when the Hover button was pressed, and stepping from there.  There was one scenario in that process that eventually led me to the frame change changing the disassembly position as well as the source code change (because the frame change output looked like breakpoint output.)

[oBFusCATed]

Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.11.patch

Fixed bug:
Watch parsing fails when string/char contains many repeating characters (http://forums.next.codeblocks.org/index.php/topic,13337.msg90084.html#msg90084)

Morten: what's up with the test project for the debugger plugin?

[MortenMacFly]

Morten: what's up with the test project for the debugger plugin?

I'm afraid I don't exactly know what you mean? Which project?

And btw: What's up with the patch(es) of cbexaminr? If you want me to do, I can apply them for a nightly so we can see how it works. If there are major reasons / bugs detected we would be able to revert it easily and do another trial... any thoughts?

[MortenMacFly]

...btw: I am facing a very strange issue myself meanwhile. I cannot debug into a project which I've created (a simple console application) anymore. The application just "runs through" no matter if I've set a BP or say run to cursor or alike. It used to work previously but fails now.

This project uses many libraries, provided through other projects within the workspace. All I can tell is that compiling is correct (I am using -g, not stripping symbols or alike) hence the only thing I can imagine is that I also compile the application with profiling information.

Could it be that newer compilers (TDM 4.5.1) in combination with newer debuggers (7.2) and enabled porofiling information does not work abnymore? Anybody experiencing the same?!

[killerbot]

occasionally it happens to me to that the debugger just races through th application and doesn't take the breakpoints into account. I haven't been able to see a structure in it though......

[MortenMacFly]

occasionally it happens to me to that the debugger just races through th application and doesn't take the breakpoints into account. I haven't been able to see a structure in it though......

Yes - that's what happens to me, too. I wonder if it's the compiler/debugger, or the plugin though.
Strange thing is that in the debugger's debug log I see that all commands are actually setup correctly.

[oBFusCATed]

I'm afraid I don't exactly know what you mean? Which project?

This one: http://smrt.is-a-geek.org/codeblocks/patches/dbg/test_dbg.zip
And btw: What's up with the patch(es) of cbexaminr? If you want me to do, I can apply them for a nightly so we can see how it works. If there are major reasons / bugs detected we would be able to revert it easily and do another trial... any thoughts?

I will take a look tonight, I've some modifications to it (simple code style + simplifications)....

About the issue: look at the debuggers log for strange messages, warnings and so on. On windows gdb is quite unreliable and produces various errors and warnings, which are not expected by C::B and break the output parser.
Also try to debug with cmd line gdb, I know it is tough, but one has to do it sometimes

[killerbot]

probably not related, but something I seem to always get (on a linux box) :
"warning: GDB: Failed to set controlling terminal: Operation not permitted"

My gdb : GNU gdb (GDB) SUSE (7.1-3.12)

[oBFusCATed]

This isn't problems... just ignore it...

[oBFusCATed]

I'm afraid I don't exactly know what you mean? Which project?

Uf, I've forgot to tell you about the test project...
It can be found here: http://smrt.is-a-geek.org/codeblocks/patches/dbg/test_dbg.zip

[cbexaminr]

Uf, I've forgot to tell you about the test project...

(actually, you didn't - it just got embedded into one of the quoted items [several posts before this one])

[oBFusCATed]

cbexaminer: I've looked at your patch, at last...

Here are some general suggestions:
1. Don't use abbreviations for the identifiers
2. Use camel-case for the identifiers: "m_myVar" instead of m_myvar

I've modified the patch a bit: http://smrt.is-a-geek.org/codeblocks/patches/dbg/disasm_changes_mine.patch
1. I've cleaned the code a bit, the behaviour should not be changed, please verify it.
2. Added a check if the disassembly dialog is visible in the step command base class.
   The old patch was executing the disassembly command even if the dialog was closed.

More changes are required:
1. You should remove all the // TBD comments
2. You should improve the comments:
   I can hardly follow them, because you've written some random thoughts or used too many words and I'm getting lost.
   The comments should be short and clear.
3. A commit message will be needed - describe all the changes please...

Please do some cleaning and then I'll look at your patch again.
I've applied it in my local copy and I hope to do some development + testing tomorrow.

[cbexaminr]

I've compared the diffs, and I did not see anything that would break the intended logical functionality I had.

I do wonder why you changed the formal parameter DebuggerDriver* type to the GDB_driver* type in the step/next classes, when everything else in gdb_commands.h is receiving a parameter type of DebuggerDriver* ?

I think I understand why you did everything else.

I do note that your patch includes the file cbplugin.h with the following change(s):
-#define PLUGIN_SDK_VERSION_MINOR 11
-#define PLUGIN_SDK_VERSION_RELEASE 13
+#define PLUGIN_SDK_VERSION_MINOR 12
+#define PLUGIN_SDK_VERSION_RELEASE 0

I don't know if that will cause you any trouble or not, but going from a 'release' of 13 to a release of '0' seems a bit strange. 

I also don't know what, if any, trouble it may cause me applying your version of the patch to move forward from...?  I expect I will not apply that part unless you advise otherwise.

Also, do you have any guesses as to why my svn diff drops/replaces the entire area of .xrc file even when I used the switches you specified?  (I observe that yours did not.)

I will try to review comments and variable case for needed changes in the next few days.