If you ever tried to either report a bug or solve it yourself, you have probably come across terms like "backtraces" and gdb (GNU Debugger). Here I will try to explain very shortly how to get meaningful backtraces on Gentoo and why you should do so.
What are backtraces and why should I use them?¶
In layman's terms, backtraces are like a flight recorder of the programme – it records the history of the programme's usage and when (and how) the programme crashed. This makes them a very useful source of information for debugging a programme – whether you do it yourself or just want to report a bug you noticed.
But in order to make them work you have to compile the programmes you want debugged with the debug symbols and then run the programme inside a debugger. Portage by default strips these symbols out of the programme, to make a smaller and thus faster binary.
How do I enable meaningful backtraces?¶
It is actually quite easy – just add two words to your /etc/make.conf and when the package recompiles next time you will have the needed debugging information for it.
The words in question are:
- add
-ggdbto theCFLAGSstring → e.g.CFLAGS="-march=native -O2 -pipe -ggdb"; and - add
splitdebugto theFEATURESstring → e.g.FEATURES="parallel-fetch splitdebug".
The two examples above are just to illustrate how cca. the string will look like later on. Do not copy-paste the rest of them!
After that is done, it is a good idea to remerge glibc with emerge -1 glibc, to make Valgrind take the debugging information into consideration. Also note that you will have debugging symbols only for the packges you emerged after you made the above two changes. You can check which debugging symbols are already present if you browse through /usr/lib/debug/.
Does it affect the performance of my system?¶
As far as I understand, not if you use FEATURES="splitdebug". This is because with splitdebug the debugging information is still stripped from the binary and saved to an external file, so the GNU Debugger, Valgrind etc. can look them up there when needed. Because the binary is still stripped from them from what I gather, you should not feel any performace drop. (Otherwise then if you would use FEATURES="nostrip", which would keep the symbols in the binary, making the programme run slower.)
What does happen is that by using the -ggdb compile flag, it takes longer for the programme to compile and it takes more disk space (tampakrap reported about 11 GiB). But unless you are in a hurry or tight on disk space, I still think it is a worthwile endavour.
So there you are: In my opinion there is no big reason why you should not be a good sport and produce meaningful backtraces. You never know when they will be needed.
More info¶
This is just a lazy man's guide, so these are the utmost very basics to help make meaningful bug reports. If you want to know anything about it you are well advised to read at least:
- the official Gentoo documentation on How to get meaningful backtraces;
- Diego Ellio "Flameeyes" Pettenò's blog post on Debug code and debug information;
- KDE TechBase also has a nice tutorial on How to create useful crash reports;
Although tempting, do not confuse the above with USE="debug", which enables debugging calls and tools of the programme itself. Unless you know what you are doing that is not what you want. And especially not when you are just trying to submit a useful bug report.
Update: added information about disk space and compile time