User forums > Help
Debug problem with header files
rhf:
A couple of weeks ago I mentioned this problem in
http://forums.codeblocks.org/index.php/topic,9203.msg65818.html#msg65818.
I also filed bug report 014526.
The problem is as follows: On Windows XP using CB SVN 5203 and gdb 6.8, if I have inline code in a header file and set a break on one of the lines, gdb does not stop at the breakpoint.
I can Step into the function from the calling statement, say from main, but breakpoints and cursor locations are ignored when I do a Continue or Run to cursor inside the function.
The following is a typical debugger log output when I set a breakpoint (on line 84) inside the function:
Setting breakpoints
Debugger name and version: GNU gdb 6.8
No source file named C:/Dev/libs/lib/inc/romberg.h in loaded symbols.
Breakpoint 2 ("C:/Dev/libs/lib/inc/romberg.h:84) pending.
Child process PID: 408
Program exited normally.
Debugger finished with status 0
From the third line above it appears there may be a symbols issue, but I don't know why.
My project settings include:
Produce debugging symbols [-g] is set
Strip all symbols from binary [-s] is not set.
Also, I have no optimizations set.
I have to debug some code from last year, and I really need to get this working. I expect that I may have modified a setting or something and would appreciate any suggestions.
stahta01:
Stop using the keyword inline.
Tim S
Jenna:
--- Quote ---GCC does not inline any functions when not optimizing unless you specify the ‘always_inline’ attribute for the function, like this:
/* Prototype. */
inline void foo (const char) __attribute__((always_inline));
--- End quote ---
quote from gcc (4.2) manual
That means the "inline" keyword should not be the problem in debugging session, if you don't have any optimization turned on.
Optimization should normally not be used with debugging.
I have issues on win with recent gdb-versions and MinGW 4.2, if the code is compiled with "-g", because gcc uses dwarf2 as default, what seems to make problems in some cases.
Using "-gstabs" in "Compiler settings -> Other options" instead works for me.
rhf:
--- Quote from: jens on October 01, 2008, 07:08:45 am ---Using "-gstabs" in "Compiler settings -> Other options" instead works for me.
--- End quote ---
Jens, thanks for the suggestion. Unfortunately, it did not solve my problem. Since apparently most CodeBlocks users do not have this problem, I probably have a mingw/gcc/gdb incompatibility. I guess I will have to use another IDE to get my work done and then later try to figure out what my problem is.
Thanks again,
Bob
rhf:
While trying to understand why I couldn't set breakpoints in header files, I discovered a possible explanation.
(I did a fresh install of TDM's bundled installer 1.803.3, http://www.tdragon.net/recentgcc/ , with gcc 4.3.2 and gdb version 6.8.).
On Windows XP using CB nightly build 21_Sep_08, svn rev 5208, I created a small two-file project with a simple inline function in a header file.
I then opened a command window and entered the same build commands that CodeBlocks uses.
Next I ran gdb from the command window to see if I could set a break in the header code. As illustrated in Case 1 below, this did not work;
// Case 1: This did NOT work.
gcc.exe -Wall -fexceptions -g -march=pentium4 -Wall -IC:\MinGW\bin -c C:\CB\main.cpp -o main.o
gcc.exe -LC:\MinGW\lib -o CB.exe main.o
// Neither of the following 2 break settings work:
(gdb) b C:/CB/Function.h:4
No source file named C:/CB/Function.h in loaded symbols.
// or
(gdb) b C:\CB\Function.h:4
No source file named C:\CB\Function.h in loaded symbols.
I then changed the slashes in C:\CB\main.cpp in the gcc command to that of Case 2 below, and now I could successfully set a breakpoint in the header.
// Case 2: This did work - the only difference is the use of forward slashes in C:/CB/main.cpp.
gcc.exe -Wall -fexceptions -g -march=pentium4 -Wall -IC:\MinGW\bin -c C:/CB/main.cpp -o main.o
gcc.exe -LC:\MinGW\lib -o CB.exe main.o
// Breakpoint is set as expected:
(gdb) b C:/CB/Function.h:4
Breakpoint 1 at 0x4017e5: file C:/CB/Function.h, line 4.
On the surface this does not appear to be a CodeBlocks problem, but I thought I would run it by you guys. I guess I could revert to an earlier compiler version, but it would be nice to get this fixed. If this is definitely not a CodeBlocks problem, I would be happy to file a bug report with the appropriate group.
Navigation
[0] Message Index
[#] Next page
Go to full version