From Fedora Project Wiki

< Changes

Revision as of 22:02, 25 February 2016 by Mjw (talk | contribs) (Add detailed description of changes necessary)

Parallel Installable Debuginfo

Summary

debuginfo packages can be installed in parallel to make it easier to observe what programs are doing or to debug when they have crashed. That way debugging, tracing or profiling programs can be done independent of whether they are 32bit, 64bit, a slightly newer or older version than currently installed or even from a different architecture.

Owner

Current status

  • Targeted release: Fedora 25
  • Last updated: 2016-02-25
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Currently only one version of a debuginfo package can be installed for a given package. Even on a multi-lib system you cannot install the 64-bit and 32-bit versions of a debuginfo package in parallel (technically you sometimes can, because of RPM file coloring, the 64bit version of the .debug files win over the 32bit version - causing lots of confusion). But there are various situation where having multiple versions of the debuginfo package installed help with tracing, profiling, debugging and/or crash analysis (see the Benefit to Fedora section below). There are various things provided by a debuginfo file that might conflict preventing parallel installation of different versions:

  • build-id file /usr/lib/debug/.build-id/xx/yyyy...yyy which is a symlink to the main ELF file.
  • build-id.debug file /usr/lib/debug/.build-id/xx/yyyy...yyy.debug which is a symlink to the .debug ELF file.
  • The .debug files under /usr/lib/debug/ with file path names mirroring the main ELF file paths under / with .debug added.
  • The source files under /usr/src/debug/<name>-<version>/

They can be made non-conflicting in the following ways:

  • The main build-id file should not be in the debuginfo file, but in the main package (this was always a problem since the package and debuginfo package installed might not match).
  • build-ids are globally unique identifiers. They will be different across arches. But might match between minor releases if the exact same ELF image is produced. The linker will get an option to hash in the full nvr to make sure all build-ids are always fully unique.
  • The .debug file names will be changed to main ELF file name-vr.debug. This name will also be set in the .gnu_debuglink section of the main file by changing the options given to eu-strip in the rpm find-debuginfo.sh script.
  • The source files will be moved under /usr/src/debug/<name>-<version>-<release>.<arch>/. This needs changes to the rpm debugedit program which rewrites the DWARF source file information.

These changes will make all files in any debuginfo file unique so they don't conflict when installed in parallel. There should be no changes necessary to programs (gdb, perf, valgrind, systemtap, systemd-coredump, eu-stack, abrt-hook-ccpp, etc.) that use build-ids or .gnu_debuglink to lookup DWARF debug information and source references for tracing, profiling and debugging.

It would be good to tweak dnf debuginfo-install to know about parallel installable debuginfo packages and maybe have an easy option to install the debuginfo for a core file or for the packages running in a container.

Benefit to Fedora

Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes