On Wed, Jan 11, 2017 at 9:31 AM, Jan Kurik <jkurik@xxxxxxxxxx> wrote: > = System Wide Change: Parallel Installable Debuginfo = > https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo > > Change owner(s): > * Mark Wielaard <mjw AT redhat DOT com> > > debuginfo packages can be installed in parallel to make it easier to > trace, profile and 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. > > > == 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). If we want to make > usr/lib/debug/ a network resource then we will need to move the > symlink to another location (maybe /usr/lib/.build-id). Unfortunately > this means a change will be necessary for debuginfo consumers to that > depend on the old location. We could keep the old symlink and point it > to the new location to work around it. But I will audit the consumers > to see which depend on it and discuss if we can have a new standard > location. > * 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. This also necessitates that we split sources out into a debugsource subpackage, and ideally this should be able to be optionally disabled, as downstream package builders may not want sources included for debugging purposes (I've seen complaints from people about being forced to disable debuginfo generation entirely because there's no way to disable including sources). I believe the SUSE guys have already done both of these things, and it would be worth it to talk to the SUSE guys about their approach and pull it in to this. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
