Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: grv575 on September 02, 2005, 09:33:45 am

Title: debugger improvements
Post by: grv575 on September 02, 2005, 09:33:45 am
I've submitted some feature requests regarding the debugger support, but one really easy one and really useful would be:


which would just issue:

(and be greyed until the program is already running of course).
This is really useful for realizing that you broke too far (some value is null when it shouldn't be) so you set an earlier breakpoint and then click restart.  Volia, it works since gdb keeps your set breakpoints when you just type run again (even loaded dll breakpoints...).
Title: Re: debugger improvements
Post by: grv575 on September 02, 2005, 05:41:30 pm
This one is even more important:

---BREAK ON Entry Point Setting---

most debuggers provide this.  either an option or a setting that allow that put a breakpoint on the program entry point so that it breaks before anything loads.

look at code blocks for example: it links against the sdk dll and manually loads the other dlls (plugins).  nothing can be done about wanting to set breakpoints on the plugin dll source lines until after codeblocks finished loading them but this is a problem with all debuggers (dlls have autorebase usually).

but... try this:
gdb codeblocks.exe
break autodetectcompilers.cpp:70

no go.  it just doesn't work.

now try this:
gdb codeblocks.exe
info target
You'll see: Entry point: 0x401220
break *0x401220
It breaks in mainCRTStartup() (within msvcrt.dll)
break autodetectcompilers.cpp:70

it works.  since codeblocks links against codeblocks.dll (sdk) it can set breakpoints within sdk/* source files on the EP (entry point) is reached.  The program hasn't run anything yet, and you can put breakpoints anywhere.  perfect
Title: Re: debugger improvements
Post by: grv575 on September 03, 2005, 06:21:51 pm
And compiler / debugger bugs: (probably applies to windows cb as well)

This probably accounts for the "Multiple file instances while debugging" bug as well.  Don't think gdb should be allowed to grab sources from other open projects (don't see why it sets source dirs for them). (linux only - but I don't know if there's a reasonable solution for this one)

Applies to the way the compiler and linker are invoked?  Is ShellExecute() being used or what set of api commands?  Calling with a an api command which passes the commanline to the system shell may help, but not sure if there are any drawbacks.