[Reproducible-builds] debugedit and reproducible builds

[Jérémy Bobbio]

Stéphane Glondu:
> 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...

Yes, that's why I started to split issues to their own subpage. Trying
to find the proper organization is not easy. But we'll get there. :)

Anyone should feel free to move stuff around as they see fit. I am all
in favor of the Wikipedia way of doing things: Bold, Revert, Discuss.
Be bold, just do what you think is right. Revert if you think a change
was a mistake and start a discussion about it.

> 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.

I can't think of a value of encoding -fdebug-prefix-map in the
DW_AT_producer attribute. The change that it produces is visible in a
DWARF field just next to it. If GCC already drops some other flags from
what it records, I think we should write a patch to add
-fdebug-prefix-map to the list and ask upstream what they think of it.

A thing to keep in mind is that -fdebug-prefix-map is a mapping
function. The directory that will be replaced must be given found and
given somehow. The first rebuild passed it through `dpkg-buildflags`,
and this unfortunately has some serious shortcomings, see #722154.

That's why I am arguing with an environment variable. It can be set in
debian/rules somehow and then any call to gcc would get the correct
DW_AT_comp_dir.

> 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?

    mkdir -p /tmp/a_test_directory/src
    cd /tmp/a_test_directory/src
    echo 'int main(int argc, char ** argv) { return 1; }' > test.c
    CFLAGS="-g -fno-merge-debug-strings" make test
    readelf -w test | grep '>.*DW_AT_comp_dir'
    debugedit -b/tmp/a_test_directory -d/usr/src -i test
    readelf -w test | grep '>.*DW_AT_comp_dir'

> (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. […]

This looks like quite an important change in the way Debian packages are
currently built. Meaning it'll be hard(er) to convince the whole Debian
community to switch to it.

> (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. […]

To me, this falls in the same kind of tricks than libfaketime. I'd
rather not go that road.

-- 
Lunar                                .''`. 
lunar at debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20140220/ff9a6836/attachment.sig>