This is the mail archive of the
mailing list for the binutils project.
building separate debug info on demand fails because CRC and build ID
- From: Steffen Dettmer <steffen dot dettmer at gmail dot com>
- To: binutils <binutils at sourceware dot org>
- Date: Mon, 22 Jul 2013 11:45:36 +0200
- Subject: building separate debug info on demand fails because CRC and build ID
I don't understand how "build-id"s and "reproducibility" work together
and how to build debug symbols on demand (with archived sources). I
searched the web but couldn't find the answers. I hope here is the
right place to ask.
My situation: on an embedded device we are using Debian with
self-compiled packages. When trouble-shooting the device, such as
analysing core files, debug libraries may be desired. So I compiled
debug libs from the same sources that were used to build the image. I
loaded the original embedded image into VirtualBox and installed my
debug libraries. What surprised me and you all know is that gdb tells
about CRC error, valgrind does not work. I read in the web that this
is caused by using debug libraries from a different build. Yes, sure!
But? My questions:
1. Why using build-id at all? I searched the web and the only hint I
found was "for speed", but I think it cannot be the full truth that
"for speed" breaks late re-building debug symbols?
2. sha1sum of .text sections of both builds match, so I think I can
safely assume I built the same binary (i.e. reproduced the original
build). But CRC mismatches. What now? So far I simply also used the
library of my build, but I think this should not be needed, it is
binary the same after all!
2. I require two builds of the same sources with the same tool chain
to produce the same binary results (to fulfill requirement of
reproducibility). I'm afraid "build id" violates this requirement. Is
it true and packages as built by Debian are not reproducible?
3. My current understanding is: ensure to be able to identify used
source code (including build rules), have identifier in the binaries
("version number", but a real one), if needed use version control
system to get original sources, have the same tool chain (for example
by specifying "install PC/VBox from THIS Debian ISO"), and be able to
rebuilt the same binary and debug symbols at any time. This does not
work for Debian packages because of build-ids. So how is it correct?
4. Is it possible to "fix" build-ids and CRCs afterwards?
Thank you for your time reading this lengthy text!