Thanks for your quick response! On 11/05/2016 12:09 PM, Ximin Luo wrote: > 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.
Ok, good that you think we're in agreement. :) > 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). Thanks for the pointers, I'll take a look. Although I'm not sure whether it'll be feasible for me to actually test this, because I don't have access to ARM hardware and compiling in qemu-user emulation is very, very slow - and gcc is a large project. (Just for comparison: dietlibc compiles in ~35s without unit tests natively on amd64 with -j4, in qemu-user with armhf as arch it takes > 10 minutes, also with -j4.) Maybe I'll see if the cross compiler is also affected, and if that's the case, I'll have an avenue. > If the FILE entry is technically "not debugging output" I do believe it is though, because if you look at the diffoscope output on tests.reproducible-builds.org, the path entry is moved to the split debug info of the executables and is not present in the executables itself anymore. Regards, Christian _______________________________________________ Reproducible-builds mailing list Reproducible-builds@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds