Install minimal debuginfo by default to increase quality of bug reports and allow easier support for profiling and user space tracing.
- Name: Alexander Larsson
- Email: email@example.com
- Targeted release: Fedora 18
- Last updated: 2012-05-07
- Percentage of completion: 0%
The debuginfo packages in Fedora are very useful if you're a developer and you are debugging a bug on your machine. However, they are very large, so they cannot be deployed in a wider scale. In many usecases you really only need enough information to be able to create backtraces, which is far smaller and could be installed by default.
The main advantage of this is a general improvement of bug report quality (as reported via ABRT or manually), as the reports will have complete backtraces from all users. Additionally things like system wide profiling and userspace tracing would also be possible without large debuginfo installation.
Debug info for backtraces relies on two types of information, the function names in the symbol tables, and (optionally) the linenumber debug information. I wrote a script that takes our current debuginfo packages and generates minimal debuginfo files containing only the minimal function name information and optionally line number information. Here are the sizes it generates for some F17 packages:
|Package||Size of executables||symbols||xz symbols||symbols+lines||xz symbols+lines|
On my F17 installation /usr is 8771 Mb, and 1861 Mb of that is made up of ELF binaries. Leading to the following estimations for full-distro sizes:
|symbols||xz symbols||symbols+lines||xz symbols+lines|
|Estimated minidebuginfo size||283Mb||43Mb||1084Mb||213Mb|
|Estimated percentage of /usr||3.2%||0.5%||12.3%||2.4%|
Compared to the current size of a Fedora install and the large churn of package update an on-disk increase of 43Mb is quite modest, so we should be able to at least ship the compressed minimal symbol table information by default.
There are several choices to be made here:
- Compressed or uncompressed
Storing the data compresses will use less diskspace, but may cause an additional performance and memory hit when using the data. This also affects how the "normal" debuginfo is handled. If accessing the minidebuginfo isn't too slow, then that information could be left out of the .debuginfo packages, making them smaller.
- Keep the data in the original or in a separate package.
If the data is kept in the originating binaries (I have patches that allows this while using compression) then supporting minidebuginfo is transparent to users, but non-optional. If we create new minidebuginfo packages for the minidebuginfo then the data can be made optional, but will require modifications to the package handling in order to automatically install and update the new packages. It also makes the change quite visible to users, as the new packages will be visible in the UI in a lot of places.
- Do we add line number information
The line number information is an additional piece of information that can be quite useful, but it is also quite a lot larger than just the symbols.
These affect the implementation chosen and must be decided initially.
Benefit to Fedora
We get better bug reports by default, even when offline or on a bad link, without users having to wait while downloading large amounts of data, or having to send possibly privacy sensitive core information to anyone. Additionally this will work for all packages built on the system (not only the official packages, but also site-specific packages) and will work with or without ABRT (some sites may not want to send bug reports to ABRT but collect them locally).
It will also make it easier to do things like system wide profiling, userspace dynamic probes and causual debugging.
Generation of the minidebuginfo just requires a few lines in /usr/lib/rpm/find-debuginfo.sh, and possibly some additional rpm macros to create new subpackages.
Consumers of debuginfo (mainly gdb, but also profilers, etc) must be changed to look in additional places for extra debug info.
If we chose to use separate rpms for the minidebuginfo we also needs modifications to the build system, the package mirroring system, the installer, the package installation tools, etc.
How To Test
Running any application under gdb you should be able to get a backtrace with function names for all frames by doing:
1. Run "gdb <program name>" 2. Type "run" 3. Do something 4. Press ctrl-c to get back to gdb 5. Type "bt" and watch the full backtrace
The end-user experience should be minimally changed. The new debug information is mainly targeted towards developers.
If using separate minidebug packages
- Possibly other package handling apps
None necessary, revert to previous release behaviour.
- No relevant documentation
- Fedora 18 ships with a small subset of debug information by default. Full debug information is still available in the debuginfo packages.