An old problem about debugger

[OnMap]

The debugger works well on my system but the following.
To start debugger, we usually have 3 choices -- start(F8), run to cursor(F4) or step into(Shift-F7). However, "step into" seems to work the same as "start", that is, it runs until a breakpoint appears, instead of breaking at 1st line in main.
This happens only at starting debugger and, if the program pauses somewhere, "step into" can be used to run step by step and run into functions as expected.
This problem exists since CB 8.02 and I have to move the cursor to main and use "run to cursor" to start debugging, though I can settle for this. Recently I update CB to svn 5322, to find that this problem still exists.
I'm not familiar with command, so I haven't directly use GDB to test.
My system is Windows XP SP2.

[ollydbg]

The debugger works well on my system but the following.
To start debugger, we usually have 3 choices -- start(F8), run to cursor(F4) or step into(Shift-F7). However, "step into" seems to work the same as "start", that is, it runs until a breakpoint appears, instead of breaking at 1st line in main.
This happens only at starting debugger and, if the program pauses somewhere, "step into" can be used to run step by step and run into functions as expected.
This problem exists since CB 8.02 and I have to move the cursor to main and use "run to cursor" to start debugging, though I can settle for this. Recently I update CB to svn 5322, to find that this problem still exists.
I'm not familiar with command, so I haven't directly use GDB to test.
My system is Windows XP SP2.

It is true, and I do meet the same problem as your said. This problem has a long history, As I can remember, it was several years ago, I used an early version of code::blocks. And I think Dec-cpp( another IDE) has the same problem.

[thomas]

I think the only bug is that the "step into" button is enabled at all, which gives the user the illusion that he is meant to use it.
When you run gdb manually and try to start a program with the step command, it will refuse to do so and instead tell you "The program is not being run". To step into main(), you'd have to set a breakpoint at the beginning of main() and run. That might be a bit outside the debugger plugin's abilities, I think.

[ollydbg]

I think the only bug is that the "step into" button is enabled at all, which gives the user the illusion that he is meant to use it.
When you run gdb manually and try to start a program with the step command, it will refuse to do so and instead tell you "The program is not being run". To step into main(), you'd have to set a breakpoint at the beginning of main() and run. That might be a bit outside the debugger plugin's abilities, I think.

Thanks Thomas for your explanation. It's informative.
There is another annoying thing, when debugging in Windows and using gdb.exe, I find that it will take several seconds (more than 10s)  to load the exe file.( for example,  I create a wxWidgets project, and try to debug it, and it seems that gdb.exe eats about 60M+ memory when loading the debugee ).

[dje]

Hi,

I have the same problem for debugging C::B plugins on XP SP3, it takes minutes on my 2005 PC to load...
Any hint is appreciated, I already disabled most of the plugins to go faster.

Dje

[ollydbg]

Hi,

I have the same problem for debugging C::B plugins on XP SP3, it takes minutes on my 2005 PC to load...
Any hint is appreciated, I already disabled most of the plugins to go faster.

Dje

Hi, try to install a recent GCC and GDB package from http://www.tdragon.net/recentgcc/
It maybe runs faster then the old version bundled in codeblocks_8.02_setup package.