1

I'm debugging a running program with gdb 6.6 on solaris, and noticed that sometimes gdb steps into (inline) functions, even though I issued a next command. My development host was recently reinstalled with a slightly newer build of solaris 10, and I know for sure the auto-stepping was not present before the host was reinstalled. The code is compiled with the same options since the makefiles and all the source code is unchanged since host reinstallation.

Is there any setting/new default option which influences gdb's debugging behaviour that I can check? Does anyone know why my gdb now auto-steps? Its a pain really ...

[edit] to clarify: I did not mean the inline keyword, but rather methods/functions which are implemented in the header file. Example:

header.hpp:
class MyClass
{
   public:
      void someFunc() { ... does something }
}

source.cc:
{
   MyClass instance;

   instance.someFunc();     // doing NEXT in gdb will actually STEP into header.hpp
}
user826955
  • 3,137
  • 2
  • 30
  • 71

1 Answers1

4

Your new version of Solaris may have included a new version of the C or C++ compiler. The new compiler may be optimizing more aggressively than it did before. Check your optimization flags. If you are using GCC, you can disable inlining with -fno-inline (note that methods that are implemented in the class in header files are inlined by default which can be disabled with -fno-default-inline). If you are using the native Solaris compiler, you will need to check its documentation.

A similar problem was reported here. In the comment, the poster mentioned changing the debug symbol to use STABS resolved the issue.

You mentioned in a comment to my answer that STABS works, but is not acceptable. Also, you mentioned that you are unable to reproduce the issue with a simple example. It will be difficult to trouble shoot this issue if you have to recompile your entire project each time to perform a test. Try to isolate the problem to a few source files in your project. See what they have in common (do they include a common header file, do they use a pragma, are the compilation options a little different from the other source fies, etc.), and try to create a small example with the same problem. This will make it easier to identify the root cause of your issue and determine how to resolve it. Without this data, we are just the blind leading the blind.

Community
  • 1
  • 1
jxh
  • 69,070
  • 8
  • 110
  • 193
  • sorry, I did not mean the `inline` keyword. edited question above for clarification. – user826955 Jun 04 '12 at 08:42
  • Can this still be caused by more compiler optimizations when I'm still on gcc 3.4.6? – user826955 Jun 04 '12 at 09:37
  • Actually I do not know whether the gdb version is different (I can't check this, the host was reinstalled due to a system failure). But I was under the impression that gcc version should be the same, since its still 3.4.6 and maybe there isn't a "newer" 3.4.6 version? We were forced to upgrade from `Solaris 10 10/08 s10x_u6wos_07b` to `Oracle Solaris 10 8/11 s10x_u10wos_17b`, which is the oldest version of solaris 10 available. I know that at least libc.so.1 is different, because we had issues deploying binaries to older production hosts with version `Solaris 10 10/08 s10x_u6wos_07b`. – user826955 Jun 04 '12 at 11:53
  • just tried, recompiled **all** involved source code with `-fno-inline` (checked all gcc outputs for -fno-inline), but it did not help. My program still steps into functions although I issue `next` commands. – user826955 Jun 06 '12 at 12:34
  • @user826955: I updated the answer to refer to another question. – jxh Jun 06 '12 at 15:07
  • I just tried `-gstabs+` and `-g` instead of `-ggdb`. In fact, the debugging worked normal (no auto-step) with `-gstabs+`. However, the output filesize was 5 times larger, which is a real no-go. `-g` also auto-stepped. – user826955 Jun 14 '12 at 07:40
  • @user826955: If the issue is only with methods that have their implementations inlined with their classes, can you try `-fno-default-inline`? Also, instead of retrying with your entire project, can you experiment with a single source file and see if you reproduce the problem with that? Regards. – jxh Jun 14 '12 at 07:47
  • I will try with the option you mentioned. So far, I was not able to reproduce with a very simple example, it only happened when compiling the project. Our compiler call is: `g++ -c -Wreturn-type -Wformat -pedantic -Wunused-variable -Wunused-label -Wunused-value -Wunused-function -Wno-long-long -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -ggdb` – user826955 Jun 14 '12 at 08:20
  • 1
    @user826955: It almost sounds to me that you have stale object files you are linking against. If you are sure all your object files are removed, perhaps check to see if your system uses a compiler cache for your objects, and if it needs cleaning? – jxh Jun 21 '12 at 15:16