On 28/08/2022 23.46, Vagrant Cascadian wrote:
On 2022-08-28, Vagrant Cascadian wrote:
On 2022-08-28, Rasmus Villemoes wrote:
On 26/08/2022 22.59, Tom Rini wrote:
On Thu, Aug 18, 2022 at 10:31:34AM -0700, Vagrant Cascadian wrote:
From: Vagrant Cascadian vagrant@reproducible-builds.org
The KBUILD_CFLAGS and KBUILD_AFLAGS variables are adjusted to use -ffile-prefix-map and --debug-prefix-map, respectively, to use relative paths for occurrences of __FILE__ and debug paths.
This enables reproducible builds regardless of the absolute path to the build directory:
https://reproducible-builds.org/docs/build-path/
Signed-off-by: Vagrant Cascadian vagrant@reproducible-builds.org Acked-by: Rasmus Villemoes rasmus.villemoes@prevas.dk
This needs some sort of clang check and then perhaps different flag used? How does the linux kernel handle this?
Well, interestingly it seems that the kernel doesn't do anything like this for debug info, they only apply the -fmacro-prefix-map. Which one should probably raise with them at some point.
It seems we're not actually calling gas directly, but always invokes $(CC) whatever that may be to compile assembler files. So I think the right fix is to simply pass the same -ffile-prefix-map in both KBUILD_CFLAGS as in KBUILD_AFLAGS - and if there's some variable that ends up being included in both automatically, then just adding it there should do the trick.
I tried just adding -ffile-prefix-map and that helped, but was not sufficient to solve the reproducibility issues. It also needs the --debug-prefix-map to make it the assembly code build reproducibly.
Though I guess I didn't try adding -ffile-prefix-map to KBUILD_AFLAGS, now that I think about it... will test that too, thanks!
Nope, that built, but not reproducibly...
That's odd. <me goes digging in gcc source> <me scratches head>
Ahh, so gcc does have logic to forward/translate a -fdebug-prefix-map to --debug-prefix-map when invoking the assembler:
#define ASM_MAP " %{fdebug-prefix-map=*:--debug-prefix-map %*}"
And for reasons that are still beyond me, gcc seems to accept --bar-baz as an alias for -fbar-baz. E.g. if I invoke
gcc -v --debug-prefix-map=/tmp=xyz-tmp-ABC --data-sections -g -o /tmp/start.o -c /tmp/start.S
gcc tells me that
COLLECT_GCC_OPTIONS='-v' '-fdebug-prefix-map=/tmp=xyz-tmp-ABC' '-fdata-sections' '-g' '-o' '/tmp/start.o' '-c' '-mtune=generic' '-march=x86-64'
and of course the data-sections was just a silly thing to highlight the alias machinery, but the point is that gcc saw this as being called with -fdebug-prefix-map=. And sure enough, the very next line which shows the assembler invocation says
as --gdwarf2 --debug-prefix-map /tmp=xyz-tmp-ABC -v --64 -o /tmp/start.o /tmp/ccu8aTZH.s
If I invoke gcc with the -fdebug-prefix-map form, exactly the same happens, i.e. gcc says it was invoked with the -fdebug form, and calls as with the --debug form.
But here's the kicker: The union option -ffile-prefix-map is not recognized by gcc's spec file machinery (the ASM_MAP macro above), so while it does affect the file paths that gcc emits to .s files when compiling .c files before handing them to gas, it has no effect when we're using gcc directly to compile .s or .S files.
I'm inclined to say that is a bug in gcc. I'll open a bug and see what they say.
I was able to guard it with "as-option":
+KBUILD_AFLAGS += $(call as-option,--debug-prefix-map=$(srctree)/=)
And it builds reproducibly for me.
That should be sufficient to fix build failures with clang... or is there a more appropriate guard to use? I am not familiar with clang and it's relevent tools to know if there is a relevent comprable option to --debug-prefix-map.
I think for clang one should just use -ffile-prefix-map unconditionally; https://reproducible-builds.org/docs/build-path/ says that should work. And when I try with 'clang -v -no-integrated-as -ffile-prefix-map=/tmp=xyz-tmp-ABC ...', it does end up invoking '/usr/bin/as --64 --debug-prefix-map /tmp=xyz-tmp-ABC'.
Rasmus