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

Splitting debugger in two - specific debugger and common GUI

<< < (60/136) > >>

ollydbg:

--- Quote from: cbexaminr on October 03, 2010, 07:49:59 am ---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.

--- End quote ---

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

--- End code ---

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:

--- Quote from: ollydbg on October 03, 2010, 09:26:08 am ---
--- Quote from: cbexaminr on October 03, 2010, 07:49:59 am ---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.

--- End quote ---
true.

--- End quote ---
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:

--- Quote from: cbexaminr on October 15, 2010, 04:22:24 am ---outstanding issue(s):
1)Does auto-switch still work properly?

--- End quote ---
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...

Navigation

[0] Message Index

[#] Next page

[*] Previous page