Splitting debugger in two - specific debugger and common GUI

[MortenMacFly]

Yes, I'll tonight

Ok guys, I looked briefly into it and I think there are indeed some benefits like the update on disassembly (not the one oBFusCATed mentioned, but in general).

However, there are also some issues like querying the UI for a setting that probably should be exchanged through configmanager.

But in fact I have an issue now: If one of you posts a patch this will break the application of the other one in the debugger branch. So I would love to see you both agree on one patch whenever something is ready.

[cbexaminr]

However, there are also some issues like querying the UI for a setting that probably should be exchanged through configmanager.

Which setting?
The "mixed" mode?
(Considering right-click popup context menu in disassembly for short-term access, but haven't attempted yet.)
Something else? 

But in fact I have an issue now: If one of you posts a patch this will break the application of the other one in the debugger branch. So I would love to see you both agree on one patch whenever something is ready.

Understood.  Obfus is definitely the current driving force here.

 I expect to piggyback off him, although I'm not sure there are any outstanding patches you haven't already applied to branch - although I haven't examined that carefully.

[cbexaminr]

Add "Mixed Mode" checkbox to disassembly dlg to enable/disable mixed mode disassembly display.  
(Actual display support of mixed mode disassembly already existed in previous patch.)

Previously considered context menu is apparently already created/owned by the control displaying the disassembly lines, and I could figure out how to do this quicker than I could figure out how to gain access to that child's context menu.

This patch is cumulative, containing all changes of first disassembly changes patch.

[edit]
Not so funny to poor, tired me (the file was on my disk, and not zero bytes, not sure what happened)

hopefully it will be there after this save

sorry Morten

[MortenMacFly]

This patch is cumulative, containing all changes of first disassembly changes patch.

Funny: This patch has 0 bytes.

[cbexaminr]

patch now has non-zero bytes, 2nd post above - bumping thread for forum visibility.

[MortenMacFly]

Hi all! Just for your interest: I've merged trunk into the branch again, as there were many new features and important bug-fixes. Revision 6647 (by Jens) caused trouble in terms of conflicts as I has expected. What I did to resolve the issues was keeping the branch's revision, so this bug fix didn't make it into the branch therefore! Probably oBFusCATed can have a look at it?!

@cbexaminr: Your patch shouldn't be affected... but you should better try again to make sure...

[oBFusCATed]

Morten: the branch is not affected by this bug, because the cbWatch/GDBWatch objects are stored in std::vector<std::shared_ptr<GDBWatch> >, so they are reference counted and the pointer is valid in the Command::ParseOutput

[oBFusCATed]

cbexaminr: some comments on the patch:

Code

         GdbCmd_Disassembly(DebuggerDriver* driver)
             : DebuggerCmd(driver)
         {
+            //TBD: Should this be 'fixed' to a position, something like
+            //"disassemble $pc" ?  I think a user messing with the debug console and disassemble
+            //could foul up the result, with that missing, but not certain...
+            cbDisassemblyDlg *dialog = Manager::Get()->GetDebuggerManager()->GetDisassemblyDialog();
             m_Cmd << _T("disassemble");
+            if(dialog->MixedMode())
+                //gdb's ordering of instructions with /m can be pretty confusing...
+                m_Cmd << _T(" /m") ;
         }

1. Progably dialog->MixedMode(), should be moved to DebuggerManager::GetMixedMode()/IsMixedMode();
2. Change the constructor from GdbCmd_Disassembly(DebuggerDriver* driver) to GdbCmd_Disassembly(DebuggerDriver* driver, bool mixedMode) and do "if(dialog->MixedMode())" only once;
3. I think the user can't fool the disassembly, because he can't enter commands while the output is processed (If it can please show how)
4. use "svn diff -x '-u -b'" to generate the patch because you've messed the formatting of src/sdk/resources/disassembly.xrc
5. else and if should be on one line, and there is a space between if and (
6. why don't you use a proper container for m_LineTypes (std::vector<LineTypeEnum>, wxArray something... (vector<bool> is not proper container in c++ < 0x) )?

I've not done any testing, but will do tomorrow ...

[cbexaminr]

cbexaminr: some comments on the patch:

I have tried to address your comments.

regarding 'mess' of .xrc file, I'll have to implicate M. (wx)Smith in that (or whatever resource editor is opened by c::b project.)

Added another button to 'quick' adjust current line position in display window.

When testing, remember my request to check the debugger log window when strange things happen.  (They probably will, they do for me.)

still needed -
1 gdbcmd_items for stepinstruction and stepintoinstruction with their own parseoutput()s and corresponding code in disassemblydlg to update the static function/line location at top.
2 observed anomalies corrected, or compensated for if gdb and/or /mi issues

anomalies observed, none 100% consistent to reproduce, but all have happened more than once, I was most recently running with local build of gdb 7.2, but have seen 1,2,3 and 4 with gdb 7.1 as well:
1 'wait for disassembly' message remains in window and no assembler code displayed
2 sometimes can be stepping instruction into/through routine with no update reflected in assembly window
3 sometimes can be stepping instruction but no stepping is occurring (debugger log seems to always shows gdb bt returning one of the messages about inconsistent psymtab vs symtab when this has occurred)
4 something like 'invalid line 0', with a display of some source file path and a number of lines (but no assembly code)
5 with mixed mode disassembly, gdb has entirely omitted some instructions from the disassembly (think in !~wxstaticbitmap() was one place I observed this (presumed gdb issue, log reflects omission), instructions are present when mixed mode disabled.

In at least one of the forms of no assembler displayed (dont remember which) log was showing gdb output with the 'dump of' header, and subsequent trailer, with no instructions in between.

[cbexaminr]

oBFusCATed,

It appears the MI interface is not currently active in the debugger branch.  I reviewed the thread and see that your first steps were to re-work some of the class organization.

Assuming I'm correct that its not active...

Is it optionally available somehow/where?
If not, what are your current plans for actually beginning to use the MI interface?  (I tried the simple approach of turning it on, and quickly found that apparently most (all?) response handling will apparently have to be modified.)

(reason desired:
Trying to wxRegEx match source/line info from responses to nexti/stepi (for disassembly location header update) is entering regex territory I've not traveled before (attempting to use non-greedy specifiers, due to windows possibility of alternate data streams which can have ':'s embedded in paths, when the response string itself uses colons for field delimiters.) From docs, looks like it would be much easier to do this with the MI responses...  
)

Thanks.

[ollydbg]

It appears the MI interface is not currently active in the debugger branch.  I reviewed the thread and see that your first steps were to re-work some of the class organization.

true.

from this page:
Mode Options - Debugging with GDB

The MI interface should be enabled by "--interpreter=mi" option, I just check the debug-log of debugger-branch, and there's no such option.

[oBFusCATed]

I'm working on gdb/mi plugin, it can be found here:

Code

URL: svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi
Repository Root: svn://smrt.is-a-geek.org/cb_gdb_mi

But at the moment requires, special patch in order to compile and work, will post it later...
p.s. at the moment gdb/mi plugin has the most basic actions/commands working (stepping/breakpoints/callstack/threads/watches), no disassembly, memory windows, no remote debugging

[MortenMacFly]

It appears the MI interface is not currently active in the debugger branch.  I reviewed the thread and see that your first steps were to re-work some of the class organization.

true.

Partially true. It's not in the branch, but you have to checkout the new debugger plugin from oBFusCATed's SVN server (svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi).

[cbexaminr]

latest (gdb-related) disasm changes effort (hopefully not zero length the first time this time)

outstanding issue(s):
1)Does auto-switch still work properly?
2)'invalid' something or other message with no actual disassembly sometimes after activating mixed mode

annoyances (that I can't do much about from within c::b with current gdb interface - mi interface may hold some hope, don't know yet):
1)(still) too much (re-)disassembly, mostly because gdb sometimes doesn't provide instruction address in its responses) - some (re-disassembly) may be due to c::b code flow, but until that caused by absence of addresses from gdb output is fixed, not worth my time pursuing.  (But think original re-disassembled for every step, so some improvement.)
2)mixed mode (sometimes) missing instructions (gdb doesn't provide them), results in no 'current' line to indicate, because its not provided by gdb
3)Have seen disassembly output from gdb seem to have extra EOLs inserted - resulted in a disassembly display of '0xQQQQQQ call ' - the called address/routine was on the next line, but disassembly 'addline()' routines didn't expect that nor know how to handle - and I don't know whether that can be regularly expected, or is some sort of gdb output anomaly.

It appears that gdb may sometimes not realize that certain instructions 'belong' to certain lines of source.  (Don't know if this is gdb issue or compiler/linker issue.)  And this may be responsible for some of annoyances(1) and all of (2) above.

[edit]re-genned patch with -x "-u -b", forgot first time - but I'm not sure it changed the .xrc diff much if at all.

[oBFusCATed]

outstanding issue(s):
1)Does auto-switch still work properly?

It works for me, if it doesn't work for you please provide details, how to reproduce it.

Sorry, I haven't much time to look at your patch, hope to do it next week, so it can be tested more...