Splitting debugger in two - specific debugger and common GUI

[oBFusCATed]

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* ?

In order to remove some casts and to document the code by itselt, now someone when reading it will know that it only works with GDB_Driver, not with CDB_Driver.

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. 

If I understand it correctly the version is something like 1.11.13 and I've modified it to be 1.12.0

to devs: Is RTTI enabled in C::B, can someone use it? On all platforms?

[cbexaminr]

devs should still confirm regarding RTTI enablement...

but if SDK is part of core, I think the following (partial) search results for dynamic_cast<> suggests RTTI is enabled everywhere core builds:

sdk\cbstyledtextctrl.cpp:        if ( EditorBase* pParent = dynamic_cast<EditorBase*>(m_pParent) )
sdk\compilercommandgenerator.cpp:    ProjectBuildTarget* bt = dynamic_cast<ProjectBuildTarget*>(target);
sdk\projectoptionsdlg.cpp:        ProjectBuildTarget* bt = dynamic_cast<ProjectBuildTarget*>(base);
sdk\replacedlg.cpp:        controlToFocus = enabledMultiLine ? dynamic_cast<wxWindow*>(txtFind1) : dynamic_cast<wxWindow*>(cmbFind1);
sdk\replacedlg.cpp:        controlToFocus = enabledMultiLine ? dynamic_cast<wxWindow*>(txtFind2) : dynamic_cast<wxWindow*>(cmbFind2);
sdk\replacedlg.cpp:            controlToFocus = chkMultiLine2->GetValue() ? dynamic_cast<wxWindow*>(txtFind1) : dynamic_cast<wxWindow*>(cmbFind1);sdk\replacedlg.cpp:            controlToFocus = chkMultiLine1->GetValue() ? dynamic_cast<wxWindow*>(txtFind2) : dynamic_cast<wxWindow*>(cmbFind2);
sdk\scrollingdialog.cpp:        // The wxRTTI is wrong for wxNotebook in < 2.8.8 and 2.9, so use dynamic_cast instead
sdk\scrollingdialog.cpp:        wxBookCtrlBase* bookContentWindow = dynamic_cast<wxBookCtrlBase*>(dialog->GetContentWindow());
sdk\templatemanager.cpp:            case totProject: prj = dynamic_cast<cbProject*>(ret); break;

[cbexaminr]

anomaly with tooltip/quickwatch hovering over marked text when using gdb

If several lines of text are marked, and the mouse pointer hovered over them, c::b will send the entire marked area to gdb as the argument to gdb's "output" command.  gdb appears to take the first non-blank characters as the argument to output, and then takes any subsequent lines as completely separate attempted commands.

In the situation I observed, the file contained the following lines of text:
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
              //SYMBOL_NAME (sym) =
              SYMBOL_LINKAGE_NAME (sym) =
                TDS_SYMBOL_NAME (info, symbol.ts_register.tsr_name);
              SYMBOL_CLASS (sym) = LOC_TYPEDEF;
              SYMBOL_TYPE (sym) =
                tds_get_type (info, symbol.ts_register.tsr_type);
//
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I had the area marked from point indicated by '^' in "SYMBOL_LINKAGE_NAME (sym) = ^" to the beginninig of the last commented line.

The debugger log shows:
>>>>>>cb_gdb:
> output
                TDS_SYMBOL_NAME (info, symbol.ts_register.tsr_name);
              SYMBOL_CLASS (sym) = LOC_TYPEDEF;
              SYMBOL_TYPE (sym) =
                tds_get_type (info, symbol.ts_register.tsr_type);
Argument required (expression to compute).
Undefined command: "TDS_SYMBOL_NAME".  Try "help".
Undefined command: "SYMBOL_CLASS".  Try "help".
Undefined command: "SYMBOL_TYPE".  Try "help".
Undefined command: "tds_get_type".  Try "help".
>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:

[oBFusCATed]

Confirmed.
There are two possible solutions:
1. Use only the first row from the selected text
2. Display an error

Which do you prefer?

p.s. what happened with the review, I'm not rushing you

[cbexaminr]

Confirmed.
There are two possible solutions:
1. Use only the first row from the selected text
2. Display an error

Which do you prefer?

Probably 1.

p.s. what happened with the review, I'm not rushing you

Started doing it in patch, botched patch up, so applied original patch but have yet to get back to comparing and applying changes in botched patch to original, and applying in code.

Maybe by this weekend.  (Life has interfered lately.)

[cbexaminr]

Next disasm .5h. changes iteration (comment changes and variable name change, should be no other code changes from oBFusCATed last mods [.5g. skipped])

Possible submit notes:
1)Check UpdateDisassembly() rather than UpdateBacktrace() for CMD_STEP_INTO_INSTR handling
2)Call NotifyCursorChanged() on CMD_STEP_INTO_INSTR and CMD_STEP_INSTR to update any of various affected windows that may be open
3)Modify disassembly display functionality in effort to
a)reduce number of times (re-)disassembly requested from gdb
b)when possible avoid total redraw of disassembly and
simply reposition "current" instruction gutter indicator
c)correct (one) possible disassembly display failure when program position
moved to lower memory address
4)Modify some of stack frame change response handling to avoid disassembly of area on
autoswitch since may not reflect current program instruction
5)Support "Mixed Mode" disassembly display
6)Add functionality to let user quickly switch "current" instruction position between top/middle/bottom of disassembly window
7)Correct cut-n-paste comment error on GdbCmd_InfoRegisters
*NOTES (with regard to mingw-built GDB 7.2):
A)Response information returned from GDB is sometimes missing current instruction address which results in some (re-)disassembly that might otherwise be avoided.  (I have not found an architecture independent means of determining the current instruction address to work-around these omissions.  GDB's "$pc" changes according to the currently selected stack frame, which may be changed by autoswitch functionality, so cannot be used.)
B)Response information returned from GDB for a mixed mode disassembly sometimes fails to include instructions that are present in the target.  Hence they cannot be found and indicated in the disassembly display.

[MortenMacFly]

Next disasm .5h. changes iteration (comment changes and variable name change, should be no other code changes from oBFusCATed last mods [.5g. skipped])

@oBFusCATed: Do you believe we should apply this now by in the branch and test it through a nightly build?

[oBFusCATed]

I will look at it tonight...

[cbexaminr]

oBFusCATed,

There was also the attach/pause patch, "attachpause.2.patch" (attached in post http://forums.codeblocks.org/index.php/topic,10908.msg91188.html#msg91188)

One of your posts (http://forums.codeblocks.org/index.php/topic,10908.msg91225.html#msg91225) seemed to suggest you had both observed the issue and seen that the patch corrected the problem (but I wasn't certain that's what you were referring to with the "Hm, works on linux" comment).

Is there currently any reason not to apply the "attachpause.2.patch" (from post http://forums.codeblocks.org/index.php/topic,10908.msg91188.html#msg91188)?

[oBFusCATed]

... (but I wasn't certain that's what you were referring to with the "Hm, works on linux" comment)....

It means that it works without the patch.

[oBFusCATed]

OK, I've finally found some time and here is the modified patch from cbexaminr: http://smrt.is-a-geek.org/codeblocks/patches/dbg/disasm_changes_mine2.patch

What I've done:
1. simplified some comments
2. renamed some variables
3. removed a block #ifdef 0 .... #endif
4. fixed the compilation without pch

If cbexaminr have no objections, the patch could be applied...

Does someone know if it is possible to remove/disable the syntax highlight for particular row?
This feature is needed for the mixed mode disassembly. At the moment all text is highlighted as ASM, which is wrong and ugly.

[cbexaminr]

If cbexaminr have no objections, the patch could be applied...

One small objection, one additional observation.

objection:
I don't think the logged message about "disasm NO match" should be removed.  I think it will be very useful for people who are wondering why an otherwise unnecessary (re-)disassembly occurred.  

Might want to change the message slightly if you think it can be more informative, but I believe it will serve a useful purpose - it's a warning about an essentially incorrect response.  I think it really shouldn't ever occur, if GDB were always returning the address information in responses.

But, if you want to answer those questions from users, I guess that's OK with me...

observation:
disassemblydlg.h seems to have acquired a
#include <vector>
the purpose of which I fail to see...

Sorry I missed those other variables you camel-cased.  I really did look for them.

[oBFusCATed]

observation:
disassemblydlg.h seems to have acquired a
#include <vector>
the purpose of which I fail to see...

4. fixed the compilation without pch (precompiled header)

objection:
I don't think the logged message about "disasm NO match" should be removed.  I think it will be very useful for people who are wondering why an otherwise unnecessary (re-)disassembly occurred. 

Hm, this message looks like it is meant for debugging, not for the users, they won't understand it.
And if I understand the code correctly, the disassembly will be generated, so this is not an error?

[cbexaminr]

its an error in that the disassembly should (usually) _not_ have to be re-generated.  That code path (I claim) should not have to exist at all if GDB always returned the correct information.

Maybe no one will complain... the code will certainly work without it, its just that when that path is taken you may be re-disassembling the same area repeatedly, which I anticipate somebody will complain about eventually, and it makes it easy to see why the re-disassembly occurred - it marks a path indicating "bad gdb output", so maybe the msg could be "disassembly, bad gdb output".  Since I don't know what triggers the instance I've seen, nor how often it or other unrecognized output may occur, tough to say just how often it will occur.

[oBFusCATed]

This info is needed for the developer of the plugin and it is there, if someone tries to understand what it is happening he/she will have a clue.
Users don't care for the implementation details...

If you needed this warning message as a user, I'm OK to re-add it, if you needed it only to debug the plugin, I'm against it

Lets minimize further talking and get this patch in the tree, OK?