Debugging is very flaky – any ideas?

[BitFlipper]

When I step through the code, GDB often hangs or instead of stepping into a function (F11), it runs the program again at full speed. This is with GDB 7.3 but I’ve tried 7.5 and it did the same thing.

Also when it gets to macros, it often becomes flaky too, either hanging or running at full speed again.

One thing I need to mention that may or may not play a part in this… My initial attempt to import a make project resulted in a gigantic VS project due to the fact that the source code tree has ~200,000 source files. It was super slow and VS was using close to 1.4 GB memory. I scrapped that project and instead created a new VS project, this time choosing not to import the files into Solution Explorer. So I manually started adding source files, but there are so many that it would be difficult to get all the dependencies in there (I’m guessing the sub-project I’m working on uses less than 10% of all the source files).

Anyone know how to resolve this issue?

[support]

Hi,

First of all, GDB performance is not related to the files inside the Solution Explorer in Visual Studio – they are handled by different mechanisms. Here is how the debugging information gets into GDB:
1. When you compile your project (either launching make directly or letting VisualGDB do it) each .c/.cpp file gets translated to an .o file containing the compiled code and the debugging info (references to source lines in source files for each function). For VisualGDB this happens ‘behind the scenes’ and VisualGDB has no direct control over it.
2. When you link your final executable, the GNU linker merges the debugging information from all .o files and puts it into the final executable file. VisualGDB does not control this directly either.
3. When you start your debugging session with VisualGDB, it runs gdb which in turn reads the debugging information from the executable file (that contains debugging sections from all .o files merged together).

The problem you are describing can have one of two reasons:
1. GDB itself has difficulties dealing with the huge amount of debugging information inside the executable file.
2. VisualGDB issues some commands to GDB that cause great delays.

In order to diagnose this further please use the GDB Session window in Visual Studio. Select the “All GDB Interaction” mode to see the commands that VisualGDB sends to GDB automatically. Before stepping into a function that usually hangs clear the GDB Session window and observe the commands that get executed afterwards. If GDB does not report the “*stopped” message for a long time, then the delays are caused by GDB itself. If it reports “*stopped” quickly, but then gets delayed while handling some command from VisualGDB, please let us know which command causes the delay.

Both cases can be solved: VisualGDB can be configured in many ways to disable certain commands (disabling some secondary features). If the cause is the poor performance of GDB itself, you can use the ‘strip’ command to remove the debug information from the object files that you do not intend to debug before you do the linking. This would reduce the size of debugging information and make GDB perform faster at a cost of not being able to debug the ‘stripped’ source files until they are recompiled again.

[Author]

Posts