Debug problem with header files

[rhf]

A couple of weeks ago I mentioned this problem in
http://forums.next.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]

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));

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]

Using "-gstabs" in "Compiler settings -> Other options" instead works for me.

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.

[TDragon]

This has been determined to be a bug in GCC's debug info generation. I'll be following up on it in the GCC bug tracker in the near future.

[RJP Computing]

This has been determined to be a bug in GCC's debug info generation. I'll be following up on it in the GCC bug tracker in the near future.

Any updates on this? I am using your latest and I still can't set breakpoints in header files? Any help would be greatly appreciated.

[ollydbg]

This has been determined to be a bug in GCC's debug info generation. I'll be following up on it in the GCC bug tracker in the near future.

Any updates on this? I am using your latest and I still can't set breakpoints in header files? Any help would be greatly appreciated.

This bug has been fixed already.
I just created a simple case, and find it works fine.

Edit:
I find it in TDM's bug list in sourceforge.
https://sourceforge.net/tracker/?func=detail&aid=2145427&group_id=200665&atid=974439

[TDragon]

Per http://www.tdragon.net/recentgcc/devel.php, I have included a patch in TDM-GCC that fixes rhf's problem. Please be much more specific about your problem.

[RJP Computing]

Sure I am using the latest version and trying to set a break point in a header only file.

Here is the file:

Code Select Expand

#ifndef WX_SERIALIZE_COMBO_BOX_H
#define WX_SERIALIZE_COMBO_BOX_H

#include <boost/serialization/nvp.hpp>
#include <boost/serialization/split_free.hpp>
#include <wx/combobox.h>
#include "ctrlsub.h"

namespace boost
{
namespace serialization
{
template< class Archive > inline void serialize( Archive & ar, wxComboBox& t, const unsigned int /*file_version*/ )
{
// invoke serialization of the base class
ar & boost::serialization::make_nvp( "wxControlWithItems", boost::serialization::base_object< wxControlWithItems >( t ) );
}

} // namespace serialization
} // namespace boost

#endif

Here is the gdb message:

Code Select Expand

Debuggee process ID: 1128
No source file named D:/devel/Utilities/MetaCapture/wxtools/wx/serialization/combobox.h in loaded symbols.
No source file named D:/devel/Utilities/MetaCapture/wxtools/wx/serialization/combobox.h in loaded symbols.

Now the debugger doesn't have any symbols for that file loaded so it never registers the break point and does not stop at the break point I set.

Any help would be appreciated. Thanks.

[rhf]

Per http://www.tdragon.net/recentgcc/devel.php, I have included a patch in TDM-GCC that fixes rhf's problem.

TDragon,
Just a quick note. You did indeed fix the header problem as you describe - which I really appreciate. However, when I migrated from your  gcc-4.3.2-tdm-2 to gcc-4.3.3 tdm-1, I began to have problems again. This is much more sporadic than before, however; and I have not been able to develop a small consistent test example. In fact, I tried to restore my system back to your gcc-4.3.2-tdm-2 release to see if perhaps the problem actually existed with the earlier version and that I had just overlooked it. Unfortunately, I have not been able to get your binaries for that previous release.

[RJP Computing]

It really seems like it has to be a header only (no .cpp) file to get the issue I am describing. Maybe that is what you are seeing.

[RJP Computing]

Do you think it has to do with the fact that it is an inline function. Can gdb debug those functions?

[TDragon]

I really need a reproducible test case to work with here, folks. The following works fine for me.

headerbrk.c

Code Select Expand


#include "headerbrk.h"
int main()
{
return DoSomething("hi");
}


headerbrk.h

Code Select Expand


#include <stdio.h>
inline int DoSomething(const char* blah)
{
printf("%s - blah\n", blah);
return 5;
}


Add to a new console project in C::B, open headerbrk.h and set a breakpoing on the printf line, start debugging, and the breakpoint is hit without any problems. Using GCC 4.3.3 TDM-1.

I shouldn't need to ask this, but are you sure you're compiling without any optimization flags and with debugging info turned on?

[rhf]

I really need a reproducible test case to work with here, folks.

I know, and it is frustrating that I can't come up with a test case as I did for the previous problem. I am currently working on a fairly large program; and every now and then, when I set a break in a header file, the debugger fails. I keep wondering if it is perhaps a problem with the project search directories, but I have not been able to identify anything obvious. Thanks again for your good work.

I shouldn't need to ask this, but are you sure you're compiling without any optimization flags and with debugging info turned on?

Yes.