13458 2019-07-26 17:11:49 +0000 Kernel embeds build paths 2019-08-29 14:41:31 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel 0.0.0 x86 Multiple RESOLVED FIXED High normal 2.8 M3 1 ross.burton bruce.ashfield randy.macleod richard.purdie tom.zanussi --- --- No (bug/feature does not impact docs) oldest_to_newest 84533 0 ross.burton 2019-07-26 17:11:49 +0000 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!? Easy enough to find that in the kernel: $ git grep 'out of pgt_buf' arch/x86/boot/compressed/kaslr_64.c: debug_putstr("out of pgt_buf in " __FILE__ "!?\n"); 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. I've now hit the edge of my knowledge. Is the build in arch/x86/boot/compressed sufficiently special that it *should* start from a clean KBUILD_CFLAGS, so it needs this added: +KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=) Or, should it *not* clear the KBUILD_CFLAGS and instead just extend or prune. Of not is that none of the other architectures reset KBUILD_CFLAGS but prune it first, so I'm guessing that is what the x86 Makefile should do too. 84535 1 ross.burton 2019-07-26 18:04:31 +0000 Decided to file this upstream too https://bugzilla.kernel.org/show_bug.cgi?id=204333 84574 2 bruce.ashfield 2019-08-02 02:24:40 +0000 arch/x86/boot/compressed has always been treated like this, since it really is quite special. I'd suggest that yes, we should just add the -fmacro-prefix-map to the Makefile and call it done, unless the maintainers can come up with a reason that the build flags are now safe to inherit. I can fix this for linux-yocto with a patch, but it won't be a universal fix until something makes it into the mainline kernel. Thoughts as to whether just fixing linux-yocto is enough for now ? 84575 3 ross.burton 2019-08-02 10:00:55 +0000 A patch to linux-yocto is a step in the right direction. I've filed an upstream bug and can engage with a friendly kernel guy here. http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=ross/reprod&id=0266c973a8076d2e4e044016ef42aae329786a6a is the patch I hacked up which seems to work. 84578 4 bruce.ashfield 2019-08-02 12:57:22 +0000 Yep, that's pretty much the same thing I did here. I'll add yours to my queue and have it out ASAP. 84753 5 bruce.ashfield 2019-08-27 15:17:26 +0000 this is fixed for linux-yocto. 84763 6 richard.purdie 2019-08-29 14:41:31 +0000 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=00ad844fe9279cc5c9005e3d096a9f4de0f33a4c