dietlibc; build path issue on ARM despite -fdebug-prefix-map

Ximin Luo infinity0 at debian.org
Sat Nov 5 11:09:00 UTC 2016


Christian Seiler:
> [..]
> 
> It appears as though gcc hard-codes the path for the startup file
> on armhf, while it doesn't do so on x86. A simple way to try this
> out, even without dietlibc:
> 
> cat > hello.c <<EOF
> #include <stdio.h>
> 
> int main()
> {
>     puts("Hello World!");
>     return 0;
> }
> EOF
> gcc -g -Wall -o hello hello.c
> readelf -Ws hello | grep FILE
> 
> On x86 the internal startup files (start.o for dietlibc, Scrt1.o,
> crti.o, crtn.o, elf-init.oS for glibc) are not referenced at all,
> while on ARM they are not only referenced, but are referenced with
> absolute paths.
> 
> The funny thing is: normally this isn't really a problem for
> reproducibility, because if the library is installed, the absolute
> paths will be something along the lines of /usr/lib/.../*.o. And
> binaries built with that path hard-coded are still going to be
> reproducible across systems. But when building a C library this
> is an actual issue.
> 

Hi Christian,

If you set a -fdebug-prefix-map=. option and it still doesn't apply it to those FILE entries, I would guess that is probably a GCC bug. You should either file it upstream or submit a patch to them.

I'm unfortunately not familiar with what is supposed to happen on ARM to suggest exactly which file to edit, to affect the final FILE entry. But for DWARF2 entries, the logic is in gcc/final.c (remap_debug_filename) and gcc/dwarf2out.c (the places where it calls remap_debug_filename).

Note that I currently have a pending patch to GCC which refactors those parts of gcc/final.c quite a bit:

https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00182.html

But they shouldn't affect you, if you decide to try to fix this. remap_debug_filename will still exist and have the same type signature - you can just call that wherever the FILE entry is output.

If the FILE entry is technically "not debugging output" then you can instead write your patch on top of my pending patch series, linked above. This defines a new environment variable SOURCE_PREFIX_MAP with the same format as debug-prefix-map, but is supposed to apply to *all* such filenames in the output, including __FILE__ etc.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git



More information about the Reproducible-builds mailing list