Author Topic: debugger improvements  (Read 6892 times)

grv575

  • Guest
debugger improvements
« 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:

debug->restart

which would just issue:
run

(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...).

http://sourceforge.net/tracker/index.php?func=detail&aid=1280373&group_id=126998&atid=707419

grv575

  • Guest
Re: debugger improvements
« Reply #1 on: September 02, 2005, 05:41:30 pm »
This one is even more important:

---BREAK ON Entry Point Setting---

http://sourceforge.net/tracker/index.php?func=detail&aid=1280759&group_id=126998&atid=707419

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.

why?
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
run
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

grv575

  • Guest
Re: debugger improvements
« Reply #2 on: September 03, 2005, 06:21:51 pm »
And compiler / debugger bugs:

http://sourceforge.net/tracker/index.php?func=detail&aid=1281125&group_id=126998&atid=707416 (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).

http://sourceforge.net/tracker/index.php?func=detail&aid=1280867&group_id=126998&atid=707416 (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.