mirror of
git://git.yoctoproject.org/linux-yocto.git
synced 2025-07-05 05:15:23 +02:00
arch/x86/boot: use prefix map to avoid embedded paths
It was observed that the kernel embeds the path in the x86 boot artifacts. From https://bugzilla.yoctoproject.org/show_bug.cgi?id=13458: [ If you turn on the buildpaths QA test, or try a reproducible build, you discover that the kernel image contains build paths. $ strings bzImage-5.0.19-yocto-standard |grep tmp/ out of pgt_buf in /data/poky-tmp/reproducible/tmp/work-shared/qemux86-64/kernel-source/arch/x86/boot/compressed/kaslr_64.c!? But what's this in the top-level Makefile: $ git grep prefix-map Makefile:KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) So the __FILE__ shouldn't be using the full path. However arch/x86/boot/compressed/Makefile has this: KBUILD_CFLAGS := -m$(BITS) -O2 So that clears KBUILD_FLAGS, removing the -fmacro-prefix-map option. ] Other architectures do not clear the flags, but instead prune before adding boot or specific options. There's no obvious reason why x86 isn't doing the same thing (pruning vs clearing) and no build or boot issues have been observed. So we make x86 can do the same thing, and we no longer have embedded paths. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
This commit is contained in:
parent
00638cdd8f
commit
55dd15336b
|
@ -38,6 +38,7 @@ KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
|
||||||
KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
|
KBUILD_CFLAGS += $(call cc-disable-warning, address-of-packed-member)
|
||||||
KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
|
KBUILD_CFLAGS += $(call cc-disable-warning, gnu)
|
||||||
KBUILD_CFLAGS += -Wno-pointer-sign
|
KBUILD_CFLAGS += -Wno-pointer-sign
|
||||||
|
KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
|
||||||
|
|
||||||
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
|
KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
|
||||||
GCOV_PROFILE := n
|
GCOV_PROFILE := n
|
||||||
|
|
Loading…
Reference in New Issue
Block a user