I have a larger C++ programm with lot of templates which i want to debug. Unfortunately gdb takes several minutes to read the symbols.
http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html contains lots of options for debugging.
Which options would you suggest to make gdb faster/more usable.
Update: It looks like the slow down is caused by libtool. If gdb is launched via libtool --mode execute it is slow. If gdb is launched gdb .libs/foo it is reasonable fast. Any ideas why is much slower?
Update: Another suggestion was -fvisibility=hidden see http://gcc.gnu.org/wiki/Visibility
Sometimes using -fdebug-types-section can make things a bit faster. It isn't guaranteed though.
Several minutes to load ... I wonder how big this executable is. If I were desperate I might try only compiling selected modules with debug info. Or perhaps look to see if it is a gdb bug. If it is split into an executable and some shared libraries, and some parts don't change very often, you could also look into using the "gdb index" feature (see the manual) to speed up the loading of debuginfo for those modules.
Related
I am using scientific linux. I am dealing with a huge amount of code in C++ with tons of cpp files. Right now, it compiles successfully, but the values/data I'm getting are definitely wrong. Also, for some small changes I make to the code causes seg faults.
In the directory user/project/Build, I enter make to compile and link all the cpp files. I then have to go to user/project/Build/bin/project to run the project binary by typing user/run/run.sh
When I go to directory /user/project/Build/bin and then type gdb project and then run, I see
Program exited with code 01. Missing separate debuginfos, use: debuginfo-install glibc..
If I try to set a breakpoint, such as by break test.cpp:19, I get the message No source file named test.cpp.
Make breakpoint pending on future shared library load?
But I clearly have a source file named test.cpp
How can I set breakpoints? Considering that I'm a beginner with Unix, should I use another IDE such as emacs or Qt creator?
Did you read the documentation of GDB? It is definitely worthwhile to read it. Read also some tutorial on gdb
If your Makefile-s are generated by cmake, you should also study the documentation of cmake and the documentation of make. See also this answer to a related question.
Did you compile all your software with g++ -Wall -g (and without any optimization flags like -O1 or -O2) - or perhaps even -g3 instead of -g?
You might even install debugging variants of the major libraries you are using (e.g. packages like glibc-debuginfo etc...)
You probably want to specify (for gdb) the source directories to search with the dir command of gdb ...
And yes, I recommend using emacs. But above all, I strongly recommend spending hours (and perhaps days or even weeks) to learn more about Linux and software development on it (there are lots of books, websites, tutorials and other training, ... about that). Maybe start with a small, hello-world like, program (learning how to compile it with g++ and to debug it with gdb). Then try to compile and debug a small (e.g. of a hundred thousand lines of source code) free software that you like (e.g. fishshell or anything you've got from sourceforge or github), just to get a feeling of how such software is built.
If you are using (or improving) a big scientific software, it probably has some community website, mailing list, or forum for help (see geant or kiva or aster as examples, which I only know by name!). Please also use them.
PS. It is not mostly a matter of choosing tools: you are using the good ones (GCC i.e. g++, emacs, gdb, make, grep or ack, etags, git, awk, ....). It is a matter to get the knowledge -spending weeks or months of your time- about how to use them wisely and combine their use. See also this & that.
I want to try google cpu profiler to analyze hotspots on a C project as an alternative to gprof so to find any differencies because i am not convinced about the accuracy gprof provides, but as i am now introducing myself to these tools i am confused about the way i should link the libraries to my program and then execute it in order to take the results for the profiling.
Keep in mind i compile the code through a makefile so i guess flags should be added there for the linking but whatever efforts i made ended in failure.
I downloaded gperf and related packages from synaptics package manager as well as installed gperf through the command line with sudo but i cant find a way to link my program to the appropriate libraries.
Any help would be appreciated, thank you.
I have a core dump generated by 2 applications -> /usr/bin/python and /usr/bin/app1.
I know the dump can be analyzed by
gdb /path/to/app /path/to/core
but is there a way to include both applications in the arguement?
I did try gdb '/usr/bin/python /usr/bin/app1' core.xxx but that doesnt seem right.
Any suggestions?
I think you cannot achieve what you want with a single invocation of gdb. But you could run gdb twice, in different terminal windows. I did that more than once, and it works quite well (except of course that your own brain could be slightly overloaded).
a gdb process can debug only one single program, with one single debugged process or (for post mortem debug) one single core file.
And a given core file is produced by abnormal termination of one single process (not several), so I don't understand your question.
Apparently, you have a crash in some execution of python probably augmented by your faulty C code. I suggest having a debuggable variant of Python, perhaps by installing the python3-all-dbg package or something similar, then use gdb on it. Of course, compile your C code plugged into Python with debugging enabled. Perhaps you violated some invariant of the Python garbage collector.
I'm trying to find a way to debug core files sent to me from released versions of my software (c++ code compiled with gcc). Ideally, I'd like to be able to deploy release builds, and keep debug builds on hand to use for debugging, so I have symbol tables, etc.
My problem is that (as I understand it) the debug and release builds are not guaranteed to be the same - so a core file from the field may just look like garbage when I fire up gdb and point to my debug executable.
Is there a way around this (and here's the catch) without impacting size or performance of my released software? It's a large application, and performance of the debug build is probably not acceptable to customers. I've looked at suggestions to build once (debug), then strip symbol tables and ship that as the release build, but I'm going to see a performance hit with that approach, won't I?
Does anyone have suggestions for things they've tried or currently use that address this problem?
Thanks!
You can compile and link with optimization turned on and still generate debug symbols (-O3 -g) and then extract the debug symbols. This way you'd have the debug symbols around but can ship without them, and you won't have a performance penalty or something. See How to generate gcc debug symbol outside the build target? on how to do that.
What are the 'best practices' when it comes to debugging core dumps using GDB?
Currently, I am facing a problem:
The release version of my application is compiled without the '-g' compiler flag.
The debug version of my application (compiled with '-g') is archived (along with the source code, and a copy of the release binary).
Recently, when a user gave me a core dump, I tried debugging it using
gdb --core=./core.pid ./my_app_debug-bin
The core was created by my_app_release-bin. There seems to be some kind of mismatch between the core file and the binary.
On the other hand, if I try
gdb --core=./core.pid ./my_app_release-bin
the core matches but I am unable to get source code line numbers (although I get the function names).
Is this what is practised? Because I feel I am missing something here.
It sounds like there are other differences between your release and debug build then simply the absence/presence of the -g flag. Assuming that's the case, there is nothing you can do right now, but you can adjust your build to handle this better:
Here's what we do at my place of work.
Include the -g flag when building the release version.
Archive that version.
run strip --strip-unneeded on the binary before shipping it to customers.
Now, when we get a crash we can use the archived version with symbols to do debugging.
One thing to note is that if your release version includes optimization, debugging may be difficult even with symbols. For example, the optimizer can reorder your code so even though the debugger will say you crashed on line N, you can't assume that the code actually executed line N-1.
You need to do some additional stuff to create binaries with stripped debug information that you can then debug from cores. Best description I could find is here
No, you don't miss anything. debug and release are just different binaries, so the core files of release don't match the debug binary. You have to look at machine code to get something from the release core dump.
You probably have to ask your user how the crash happened and collect additional log information or whatever you app produces.