Splitting debugger in two - specific debugger and common GUI

[etheranger]

+ Added workaround to correctly set working dir (can still be disabled by #undefining ENABLE_WORKINGDIR_WORKAROUND.

Have you tried to pass the .create command in the -c command line option?

Yeah, even with an opening command with -c, CDB still won't run unless you pass in a .exe on the command line (cdb.exe -c ".create myprog.exe" isn't a valid usage). I tried throwing a -c ".createdir workingdir" in, but it gets executed after the debuggee has already been launched
If there was some kind of standard dummy executable we could use instead of the process I'm killing (like `true` in gnu) that would be nice, but as far as I can see the only .exe we can be sure of existing is the debuggee.

Hm, it seems that the breakpoints are a bit broken. The current position marker is displayed 1 line after the breakpoint.
Etheranger, Morten do you see this problem, too?

As far as I can see, it seems to be correctly stopping directly on the breakpoint. Is it possible yours is on a line that's being optimised out / otherwise non-executable?

[oBFusCATed]

OK, I'll try some things and if they don't work, the workaround will stay.

breakpoints:
The executable is build with /Zi /Od (or /0d) /MDd and it stops on the next line.
Here is the version of the debugger "Microsoft (R) Windows Debugger Version 6.11.0001.404 X86".
 I'm using the latest nightly, without your changes.

Code

Command-line: c:\Program Files\Debugging Tools for Windows (x86)\cdb.exe -G -lines -y C:/dev/projects/tests/cdb_test/; -srcpath C:/dev/projects/tests/cdb_test/; bin/debug/cdb_test.exe
Working dir : C:\dev\projects\tests\cdb_test\
> bc *
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: bin/debug/cdb_test.exe
Symbol search path is: C:/dev/projects/tests/cdb_test/
Executable search path is: 
ModLoad: 00400000 0040f000   cdb_test.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 10480000 10557000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCP90D.dll
ModLoad: 10200000 10323000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll
(300.115c): Break instruction exception - code 80000003 (first chance)
eax=00251eb4 ebx=7ffdb000 ecx=00000003 edx=00000008 esi=00251f48 edi=00251eb4
eip=7c90120e esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll - 
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000> 0:000> 
> bu1 `C:/dev/projects/tests/cdb_test/main.cpp:40`
*** WARNING: Unable to verify checksum for cdb_test.exe
0:000> 
> l+t
Source options are 1:
     1/t - Step/trace by source line
0:000> 
> l+s
Source options are 5:
     1/t - Step/trace by source line
     4/s - List source code at prompt
0:000> 
> l+o
Source options are d:
     1/t - Step/trace by source line
     4/s - List source code at prompt
     8/o - Only show source code at prompt
0:000> 
> g
Breakpoint 1 hit
>   40:     printf("curr dir: %s\n", curr_dir);
0:000> 
> k n
 # ChildEBP RetAddr  
00 0012ff68 00405058 cdb_test!main+0x45 [c:\dev\projects\tests\cdb_test\main.cpp @ 40]
01 0012ffb8 00404e9f cdb_test!__tmainCRTStartup+0x1a8 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll - 
02 0012ffc0 7c817077 cdb_test!mainCRTStartup+0xf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 403]
WARNING: Stack unwind information not available. Following frames may be wrong.
03 0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49
0:000> 
> q
quit:

As you can see the debugger returned the correct line, but in C::B it is +1.

Code

Breakpoint 1 hit
>   40:     printf("curr dir: %s\n", curr_dir);

[oBFusCATed]

OK, I've done some modifications to the etheranger's patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/cdb_fixed.patch

1. I've removed the workaround, instead of the killing, CDB is executed at the working directory.
2. CDB launches separate cmd window for console applications
3. Done some refactoring here and there

Please test and report if there are any problems...


p.s. etheranger you've fixed the breakpoint+1 problem

[etheranger]

That seems to all be working fine for me so far.

I'd tried something similar with the working dir earlier, but I missed making the debuggee path absolute, so codeblocks.cbp stopped running for me
Obviously you've fixed that, and I take it the algorithm for populating source directories to pass to the debugger always returns an absolute path.

Nice!

[oBFusCATed]

Morten: go go go with the commit

[MortenMacFly]

Morten: go go go with the commit

...done. Good work!

[oBFusCATed]

Thanks Morten, you can close the patches in Berlios, if you've not done so already 

[dmoore]

Obfuscated: Any chance you can help me use your Debugger API to write a plugin for Python debugging? (I have some very old code -- a massive hack -- where I tried to do this but your work would make it much simpler and better integrated). And by "help", I mean tell me what to look at to get started, tell me what I'm doing wrong when I hit a wall etc. You don't have to provide any code.

[oBFusCATed]

Yes, I can and I will be glad

The two things you can look at are the debugger plugin in the cb's svn and my try at gdb/mi plugin.
My plugin can be accessed with svn at svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi (at the moment I think it fails to compile).

The basic idea is: you make a plugin, derive from cbDebuggerPlugin, then you implement all the virtual methods

Take a look at both plugins and if you have questions ask

[dmoore]

I spent an hour or so today looking through the code. I think I have a rough understanding of the new features. I have a few basic questions.

1. Just to be sure, is the latest SDK code here:

svn checkout http://svn.berlios.de/svnroot/repos/codeblocks/branches/wxpropgrid_debugger

To save me some reading/testing:

2. How does the handling of multiple debuggers work? Do they all share the same ui elements? What happens when a user switches between debuggers using the active debugger menu option? (e.g. what happens to the ui elements such as the watch, stack etc?) If plugin 1 is already debugging, can I switch to plugin2 and start a new debugging session and keep the session in plugin1 active? (And will the framework update the ui appropriately when I switch between them?)

3. For a python application, it probably makes the most sense to start debugging the active file in the editor (rather than the active target). Is that going to be a problem?

4. What is the purpose of OnAttachReal/OnReleaseReal? I hope we never see OnAttachReallyReallyReal

Thanks for the good work on this, oBFusCATed.

[oBFusCATed]

1. Yes, this is it
2. They share the UI and there is Manager::Get()->GetDebuggerManager()->GetActiveDebugger(). You can change the active debugger with Debug->Active debugger. I think the active debugger can't be changed during the debug session. This should change in the future, but I've not thought about it, much. Probably it should be possible to debug with a combination of plugins  -> 'C++ + python' or 'c++ + lua' (I use this combination, but no lua debugger at the moment )
3. No problem, there is a Start method or something like that. There you can do whatever you like or is appropriate.
4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end

[MortenMacFly]

4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end

How about renaming the first to "OnAttachBase" and the speci alised methods to "OnAttach"?!

[Jenna]

4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end

How about renaming the first to "OnAttachBase" and the speci alised methods to "OnAttach"?!

Or OnAttach and DoAttach, as we do it on other places.

[oBFusCATed]

+1 for Jens' suggestion
-1 to Morten's, because OnAttach is declared in cbPlugin, so I can't change its name.

Another options is

Code

MyPlugins::OnAttach(...)
{
    cbDebugger::OnAttach(...);
    ....
}

But I don't like it too much.

[dmoore]

1. Yes, this is it
2. They share the UI and there is Manager::Get()->GetDebuggerManager()->GetActiveDebugger(). You can change the active debugger with Debug->Active debugger. I think the active debugger can't be changed during the debug session. This should change in the future, but I've not thought about it, much. Probably it should be possible to debug with a combination of plugins  -> 'C++ + python' or 'c++ + lua' (I use this combination, but no lua debugger at the moment )
3. No problem, there is a Start method or something like that. There you can do whatever you like or is appropriate.
4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end

Based on this, I should be able to simply reuse large chunks of my old Python Debugger Plugin then gradually refactor it. I'll hopefully report back next week...