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

Splitting debugger in two - specific debugger and common GUI

<< < (64/136) > >>

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:

--- Quote from: oBFusCATed on October 23, 2010, 09:16:32 pm ---Also, what do I need to do to reproduce the case, that requires the introdution of GdbCmd_ChangeFrame?

--- End quote ---
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.codeblocks.org/index.php/topic,13337.msg90084.html#msg90084)

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

MortenMacFly:

--- Quote from: oBFusCATed on October 28, 2010, 12:04:20 am ---Morten: what's up with the test project for the debugger plugin?

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version