User forums > Using Code::Blocks
GDB question and linked static libs...
gerard:
I installed C::B today after trying things like Dev-C++, Eclipse & CDT, Vs2005 C++ Express, etc, etc., for use as a C++ IDE with debugging.
None of the other IDEs had any decent GDB or other debugger support, so C::B is looking promising. Otherwise I'm going to opt for using Visuall C++ IDE from Microsoft. :P
Problem I am having is getting GDB (6.3) to stop at break points. In C::B I have a main project (Windows GUI) and I have created another project in the same workspace where I place common libraries in a static library (.a file). All paths, etc, are sorted out properly so the library builds with debugging support (-g3 option) and so does the main GUI application.
I place a breakpoint in the main application where it creates an object from a class defined in the static library. I then have a breakpoint in that classes constructor.
When I do a "step into" from the main application, or do a continue, I am expecting it to hit the breakpoint in the class constructor. The continue however skips all that and the application runs and never hits the break point. The step-into hits some arb blank line in a header file used in the static library. It's just a blank line, there are no inline methods defined in that header either. It reports "no line xxx in file yyy.h".
I have tried various versions of GDB and tried to build version 6.5 as well without much success.
I have used the mingw that comes with C::B, and also the stuff that comes with Dev-C++, etc., but no luck. They all just hit the same blank line in the header file.
What's the deal with this?
This is all on a P4 3GHz running Win2K (SP4) with C::B 1rc2
sethjackson:
--- Quote from: gerard on July 28, 2006, 05:01:47 pm ---I installed C::B today after trying things like Dev-C++, Eclipse & CDT, Vs2005 C++ Express, etc, etc., for use as a C++ IDE with debugging.
None of the other IDEs had any decent GDB or other debugger support, so C::B is looking promising. Otherwise I'm going to opt for using Visuall C++ IDE from Microsoft. :P
Problem I am having is getting GDB (6.3) to stop at break points. In C::B I have a main project (Windows GUI) and I have created another project in the same workspace where I place common libraries in a static library (.a file). All paths, etc, are sorted out properly so the library builds with debugging support (-g3 option) and so does the main GUI application.
I place a breakpoint in the main application where it creates an object from a class defined in the static library. I then have a breakpoint in that classes constructor.
When I do a "step into" from the main application, or do a continue, I am expecting it to hit the breakpoint in the class constructor. The continue however skips all that and the application runs and never hits the break point. The step-into hits some arb blank line in a header file used in the static library. It's just a blank line, there are no inline methods defined in that header either.
I have tried various versions of GDB and tried to build version 6.5 as well without much success.
I have used the mingw that comes with C::B, and also the stuff that comes with Dev-C++, etc., but no luck. They all just hit the same blank line in the header file.
What's the deal with this?
This is all on a P4 3GHz running Win2K (SP4) with C::B 1rc2
--- End quote ---
Heh we need to add this to the FAQ or something :lol:
It is a bug of GDB unfortunately. :P
http://forums.codeblocks.org/index.php?topic=613.0
Also you are using rc2. You really need to use a nightly build. ;)
Charon:
hi,
there were lots of bugfixes and additions in the nightly build considering debugging.
i don't know if these fixes will help you with your specific problem but the chances are quite high.
so get yourself a nightly build and try it again!
(but be sure to read the howto for the installation since nightly builds don't have an installer and don't come with their own copy of mingw)
regards
Markus
[edit]
argh, got beaten to it...
but yeah now i remember this myself :
to jump into a constructor during debugging with GDB you need to create an empty member-function in your class, call it first in your constructor and set your breakpoint inside this member-function.
[/edit]
gerard:
I'll get a nightly build. Thanks.
Ain't this all going to look way too messy? Lots of ifdef DEBUG stuff everywhere to have a empty member function in the class just to trap the breakpoint.
Liveable if it works, though. :) Will give it a try.
thomas:
--- Quote ---I place a breakpoint in the main application where it creates an object from a class defined in the static library. I then have a breakpoint in that classes constructor.
When I do a "step into" from the main application, or do a continue, I am expecting it to hit the breakpoint in the class constructor. The continue however skips all that and the application runs and never hits the break point.
What's the deal with this?
--- End quote ---
The deal with this is that setting breakpoints in constructors does not work reliably with "plain normal" gcc / gdb. This has nothing to do with Code::Blocks, and it will not be better after installing a nightly build (however, it is very much worth using a nightly build nevertheless).
The compiler generates several versions of a constructor to implement virtual base classes (no matter whether the class is virtual or not). Don't ask me why, ask a guy from the gcc team if you're interested why that has to be like this.
The problem is that all these constructors obviously have the same name. They're mangled differently, so the linker will find the correct one, but the "visible" name is still the same. While they have the same source name, they are nevertheless different things.
So what happens if you set a breakpoint? The debugger uses names as they're found in the source, and it cannot reliably set a breakpoint into the correct thingie (it doesn't know which one).
There are patches for gcc and gdb that follow various strategies to work around this, but that's all non-standard stuff.
An easy way to work around this limitation is to call a dummy function from inside the constructor and set your BP in there (there is only one version of that dummy func, so there's no problem).
Navigation
[0] Message Index
[#] Next page
Go to full version