weird gdb issues...

[Kreso]

so far I've noticed 2 problems with gdb in C::B :

1) it cant break at the first line in main()
2) breakpoints in class constructors seem to be ignored


I'm using ubuntu Linux 6.06, C::B latest svn build. I've tried this with GDB 6.3,6.4 and 6.5, same thing.

[thomas]

1) Works fine, although you should notice that you generally cannot break on everything.
For example, POD variable declarations and constant initialisers usually don't work as breakpoints.
This is not limited to the first line in main() though.

2) Is a known feature of gcc and gdb. This is due to how the compiler implements constructors.

[marfig]

Search the forums for "gdb constructor" for a few tips on dealing with 2)

[Kreso]

1) yes ofcourse, I know that but I mean ,actual lines, like function calls(), it never breaks on the first line

[Kreso]

I've tried the dummy() workarround and it works

maby this could be included in C::B as a debugger option, so whenever a breakpoint is set in a constructor/destructor, c::b makes a dummy() function for every such breakpoint, sets the breakpoint and automaticly steps when gdb breaks?

Can this be made with the plugin sdk? if so, I volunteer to do this

[thomas]

This would mean to recompile and relink each time you set or unset a breakpoint. It may be better to use the regex method (and possibly loop through next until At: says you're in the line you want).

[Kreso]

This would mean to recompile and relink each time you set or unset a breakpoint. It may be better to use the regex method (and possibly loop through next until At: says you're in the line you want).

well not necesarily, you could like create a hidden cpp file where you would make lets say, 50 dummy functions, each with a different name ofcourse, and if the user checks that workarround option, you always compile that file with the rest of the project, and just set/unset breakpoints whenever the user sets them in the constructor.

[mandrav]

I've tried the dummy() workarround and it works

maby this could be included in C::B as a debugger option, so whenever a breakpoint is set in a constructor/destructor, c::b makes a dummy() function for every such breakpoint, sets the breakpoint and automaticly steps when gdb breaks?

Don't get your hopes up, this will never be included in C::B.
It is an IDE for developers. You are the developer, you should know what to do. The IDE should never perform such drastic operations like adding a hidden file to your project and compiling/linking it with the rest of your files  :shock: .

This constructor-breakpoints issue is a known shortcoming of gdb. Learn your way around it. Don't expect your IDE to perform complex tasks to do it for you (which is not guaranteed to work anyway).

[Kreso]

I know, I know, but still

just tell me one thing: can the method described above me made with the C::B plugin sdk? if so, I'll get right on it, and it will serve as a temporary solution until gdb fixes the issue.

[thomas]

This can certainly be done with the Code::Blocks SDK, it just isn't good practice and it doesn't make much sense.

You can query a projectfile's filename from ProjectManager, and you can certainly tell it to use some different file, too. You'll only have to manage swapping in the right thing when the user compiles and swapping it back when the user edits a file (which can happen while the IDE compiles).
All in all, it's a terrible hack. Don't come running when it eats your cat... 

[Kreso]

hmm, good point