Splitting debugger in two - specific debugger and common GUI

[cbexaminr]

relative to disasm.changes.4.patch

re-instate code to populate disassembly header info (erroneously removed)
changes to not break autoswitch but still disassemble last current step location
remove some garbage

[cbexaminr]

For MSW/GDB, Pause-Break(/Stop) actions don't work when process has been 'attached'.  (Guessing similar could be true for non-MSW compilation path as well...?)

Appears can be corrected for MSW by addition in DebuggerGDB::DoBreak(bool temporary) of
if(pid <= 0) //Did child lookup succeed?
  pid = m_PidToAttach ;

in appropriate location after effort has been made to find 'child' in table, with failure

Also, is there a reason to continue searching table after a child has been found? Can there be more than one 'child' that would match? 

And, could log an error if one reported from call of DebugBreakProcess().

I've attached a patch _only for reference_ that includes changes that address most of these comments, BUT, it is also dirtied with other as yet unapplied items in my disasm patch(es).  (The changes pertinent to these comments are those in the DebuggerGDB::DoBreak() method.)

[oBFusCATed]

Patches can be edited with a text editor, so you could remove the disasm-changes from your patch.
Also you could checkout the tree in another directory

[MortenMacFly]

relative to disasm.changes.4.patch

I'm afraid you'll need to re-do this for the current version in the branch as this has been modified heavily due to the merge. I am very sorry for this inconvenience.

[oBFusCATed]

There is a build problem:

Code

/home/obfuscated/projects/codeblocks/brances/wxpropgrid_debugger/src/sdk/nullptr.cpp:16: error: ‘null_pointer_t’ does not name a type

It seems that the nullptr.cpp is not added to the trunk's Codeblocks-unix.cbp

[cbexaminr]

I was composing a question regarding this... when you posted...

I suspect nullptr.cpp is supposed to be _removed_ from the project, as it appears that null_pointer_t definition has been removed from src/sdk/prep.h, and replaced with something different to define a const "nullptr" item directly in prep.h...

But I don't know... [edit] branch built for me after _removing_ nullptr.cpp from c::b project...

[oBFusCATed]

Here is http://smrt.is-a-geek.org/codeblocks/patches/dbg/pch_build_2010_10_22.patch the full patch I'm using to build the debugger branch.

I build without pch, so most of the patch is related to include fixes.
Loaden you owе me a virtual cake :-P


p.s. this patch could be applied to trunk with minor modifications, I've not tried it because I don't use trunk...

[cbexaminr]

relative to disasm.changes.4.patch

I'm afraid you'll need to re-do this for the current version in the branch as this has been modified heavily due to the merge. I am very sorry for this inconvenience.

C'est la vie.

.5. patch redone after merge - plus...

Also includes the suggested changes and possible fix for pause-break(/stop) not working for 'attach'ed process.  Also has addition of guessed change for the non-MSW path, but that is not even compiled.

[oBFusCATed]

Please separate the patches...I'm sure it won't be too hard...

BTW the old patch is working without problems...

[cbexaminr]

separated

plus tipwindow experimental changes patch, just in case you'd forgotten.  (I think its free of the eol property issues now as well.)

[oBFusCATed]

cbexaminr:

Can you explain the steps needed to reproduce the bug you try to fix with the attachpause.2.patch ?

The disassembly patch seems to cause the output command for the tooltip to be executed 3 time, can you investigate that?

p.s. I'm running gentoo linux amd64, if this can make a difference
p.p.s. The DebugBreakProcess is available in win2000+, so the debugger can't work in win98/ME

[cbexaminr]

cbexaminr:

Can you explain the steps needed to reproduce the bug you try to fix with the attachpause.2.patch ?

On windows, Start c::b, attach to a process that you do not have a project open for, but which has been previously started outside of c::b.  An initial break will occur (on windows at least) as a result of the initial attachment.  Continue the target process from c::b.   Then attempt to 'pause' the running process (I was using the toolbar icon, don't think I tried the menu option.)

(Codewise, the process is not paused, because m_Pid is not populated for an attached process, and a child is not found to attempt the 'break' on.)

I'm assuming similar circumstances would occur on Linux as well, assuming m_Pid and m_AttachToPid are handled the same as windows, but I didn't actually explore this outside of DoBreak().

The disassembly patch seems to cause the output command for the tooltip to be executed 3 time, can you investigate that?

OK, I'll see what happens to me on windows. 

p.s. I'm running gentoo linux amd64, if this can make a difference

Don't know, could be some difference.

[oBFusCATed]

Hm, works on linux, should do some testing on windows....

BTW, m_Pid is the PID of the debugger

p.s. the GdbCmd_StepOrNextInstruction and similar classes in the Disasm patch seems to be unused, can I remove them?

[cbexaminr]

The disassembly patch seems to cause the output command for the tooltip to be executed 3 time, can you investigate that?

OK, I'll see what happens to me on windows.  

Get three commands, but not repeats.

For a boolean variable bFirstTime, the three slightly different commands executed were:
whatis bFirstTime
output &bFirstTime
output bFirstTime

were all executed obtaining 1)type information, 2)address, and 3)variable contents.

Could that be what you are seeing?  The disassembly patch has nothing to do with that, though.

[cbexaminr]

p.s. the GdbCmd_StepOrNextInstruction and similar classes in the Disasm patch seems to be unused, can I remove them?

No.  I'm pretty sure you'll find they are used if you remove them and try compiling.  That one is a base for the other two commands.  At the moment they're similar, but I chose to give each action its own command class in case they should need to diverge.