[Reproducible-builds] debugedit and reproducible builds

Stéphane Glondu glondu at debian.org
Wed Feb 19 09:49:09 UTC 2014

Le 19/02/2014 00:29, Jérémy Bobbio a écrit :
>> I am not very comfortable with fiddling with ELF files like that. Isn't
>> it possible to directly tell gcc (or whatever is responsible) to
>> directly write the right path in the first place?
> We can do that with -fdebug-prefix-map. Unfortunately, that very own
> lines get recorded into the DWARF files. So we don't only need
> -fdebug-prefix-map but also -gno-record-gcc-switches.
> See https://wiki.debian.org/ReproducibleBuilds#DWARF_data

I didn't pay attention to this section in this (very dense) page... I
have many thoughts on that.

On one hand, -gno-record-gcc-switches seems extreme, and knowing the
options used for compilation can have its use for debugging. However,
the documentation for the dual option, -grecord-gcc-switches, says:

> This switch causes the command-line options used to invoke the compiler
> that *may affect code generation* to be appended to the DW_AT_producer
> attribute in DWARF debugging information.

This phrasing suggests that command-line options may be dropped from
DWARF information (for example, -Wall is not recorded). Does anyone know
whether -fdebug-prefix-map is recorded merely by default or, if not, the
rationale of why it is intentionally recorded? If it is not intentional,
maybe we could directly argue with upstream gcc to not record it.

On the other hand, it would be nice if switches could be selectively
recorded, e.g. by surrounding excluded one by -gno-record-gcc-switches
and -grecord-gcc-switches... but it doesn't seem to work
(-gno-record-gcc-switches always prevails). This pattern of surrounding
switches by others is already done e.g. when one wants to link
statically or with --as-needed only one library.

> If GCC would support an environment variable, maybe that would work
> better.

If it would, I expect whatever is "relevant" in it to be recorded by
-grecord-gcc-switches as well.

> The debugedit path is what Fedora and Red Hat do, and that felt like a
> valid path. Part of my reasoning was that if you build from your Debian
> package sources (e.g. using debian/rules binary), you might want to
> run `gdb ./hello` and have GDB look up the source code in the right
> place.

I spent some time on adjtimex. debugedit does not seem to have any
effect one it. Admittedly, it doesn't use dpkg-buildflags, but I
manually added the options and it still doesn't do anything.

Even on a simple main.c with a main function in a regular Debian
environment, debugedit does not seem to do anything. I must be missing
something... Can someone give me a sequence of steps to exhibit
debugedit behaviour?

(Alternative-1) As an alternative to debugedit, I believe it is possible
to write a gcc wrapper that makes it write the canonical location to its
output. After stracing and ltracing gcc, I figured out that overriding
getcwd() is enough to make it use whatever path we want. The wrapper
script would then set LD_PRELOAD and some other variables to configure
the preloaded library and exec gcc. But I must admit this is hackish and
not very future-proof :-) Moreover, it would be gcc-specific.

(Alternative-2) Another alternative to debugedit could be to use proot,
with a binding that puts the source tree at its canonical location, then
builds the package in the faked /usr/src. For example, when I do this
(in the reproducible chroot):

    $ mkdir -p /tmp/src/a
    $ cd /tmp/src
    $ ( cd a && apt-get source adjtimex )
    $ cp -a a b
    $ ( cd a && for u in *.dsc; do proot -b $PWD:/usr/src sh -c "cd
/usr/src/${u%%_*}-* && exec dpkg-buildpackage -us -uc"; done )
    $ ( cd b && for u in *.dsc; do DEB_BUILD_TIMESTAMP=$(date +%s -d
"$(sed -n -e 's/^Date: //p' ../a/${u%%_*}*.changes)") proot -b
$PWD:/usr/src sh -c "cd /usr/src/${u%%_*}-* && exec dpkg-buildpackage
-us -uc"; done )

I get identical binaries, even with an unpatched debhelper. I know proot
can be controversial (it uses ptrace, it is not available on all
architectures), but I believe adding an option similar to -r for proot
to dpkg-buildpackage will be less controversial and could be accepted
upstream. And as far as I understand, the feature of proot used here is
basically a built-in feature of hurd, and might also become cleaner on
Linux with the recent namespace developments.



More information about the Reproducible-builds mailing list