lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAK7LNASsiYHK3QW5aOg016_XwD-MmOOcJ6UA=f95BxEZ-p+gSw@mail.gmail.com> Date: Fri, 18 Mar 2022 14:15:07 +0900 From: Masahiro Yamada <masahiroy@...nel.org> To: Mark Brown <broonie@...nel.org> Cc: kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev, kbuild-all@...ts.01.org, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Michal Marek <michal.lkml@...kovi.net>, Nick Desaulniers <ndesaulniers@...gle.com>, Linux Kbuild mailing list <linux-kbuild@...r.kernel.org> Subject: Re: [broonie-misc:arm64-sysreg-gen 6/9] arch/arm64/include/asm/sysreg.h:125:10: fatal error: 'generated/asm/sysreg.h' file not found On Thu, Mar 17, 2022 at 2:05 AM Mark Brown <broonie@...nel.org> wrote: > > On Wed, Mar 16, 2022 at 05:56:39AM +0800, kernel test robot wrote: > > Not deleting context for the benefit of the kbuild people I just CCed... > > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git arm64-sysreg-gen > > head: 72b2ee21681c0c515c6a8bb62bd289766ce324a1 > > commit: caf0e02eaa9ed9bfa50642f0bc2ee008b1c138ff [6/9] arm64/sysreg: Enable automatic generation of system register definitions > > config: arm64-randconfig-r006-20220313 (https://download.01.org/0day-ci/archive/20220316/202203160508.k7vz4ZxC-lkp@intel.com/config) > > compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project a6b2f50fb47da3baeee10b1906da6e30ac5d26ec) > > reproduce (this is a W=1 build): > > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > > chmod +x ~/bin/make.cross > > # install arm64 cross compiling tool for clang build > > # apt-get install binutils-aarch64-linux-gnu > > # https://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git/commit/?id=caf0e02eaa9ed9bfa50642f0bc2ee008b1c138ff > > git remote add broonie-misc https://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc.git > > git fetch --no-tags broonie-misc arm64-sysreg-gen > > git checkout caf0e02eaa9ed9bfa50642f0bc2ee008b1c138ff > > # save the config file to linux build tree > > mkdir build_dir > > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=arm64 prepare > > > > If you fix the issue, kindly add following tag as appropriate > > Reported-by: kernel test robot <lkp@...el.com> > > > > All errors (new ones prefixed by >>): > > > > In file included from kernel/bounds.c:10: > > In file included from include/linux/page-flags.h:10: > > In file included from include/linux/bug.h:5: > > In file included from arch/arm64/include/asm/bug.h:26: > > In file included from include/asm-generic/bug.h:22: > > In file included from include/linux/printk.h:9: > > In file included from include/linux/cache.h:6: > > In file included from arch/arm64/include/asm/cache.h:8: > > In file included from arch/arm64/include/asm/cputype.h:173: > > >> arch/arm64/include/asm/sysreg.h:125:10: fatal error: 'generated/asm/sysreg.h' file not found > > #include "generated/asm/sysreg.h" > > ^~~~~~~~~~~~~~~~~~~~~~~~ > > 1 error generated. > > This looks like a kbuild thing which as far as I can see only exists for > O= builds and possibly only with bounds.s - if I look at the full log I > see that we correctly generated asm/sysreg.h: > > GEN arch/arm64/include/generated/asm/sysreg.h > > but that's only passed to CC (at least for bounds.s) via an > -I./arch/arm64/include/generated so won't be found with the generated/ > prefix. While this can be avoided by renaming the header and not > referencing it with the prefix I do see a bunch of other headers > throughout the tree being included with an explicit generated/ prefix so > I'm not sure this is what's supposed to be happening, it does seem like > a landmine somehow. Do not add 'generated/' prefix. Let's think about this scenario. First foo.h was hard-coded, but sometime later, somebody noticed it is better to generate it by scripting. Why do we need to fix up #include <foo.h> to #include <generated/foo.h> in all the call sites? Or do we need to have foo.h to wrap <generaged/foo.h> ? No, users of foo.h do not need to know if it is a checked-in header of a generated one. > > > make[2]: *** [scripts/Makefile.build:121: kernel/bounds.s] Error 1 > > make[2]: Target '__build' not remade because of errors. > > make[1]: *** [Makefile:1191: prepare0] Error 2 > > make[1]: Target 'prepare' not remade because of errors. > > make: *** [Makefile:219: __sub-make] Error 2 > > make: Target 'prepare' not remade because of errors. > > > > > > vim +125 arch/arm64/include/asm/sysreg.h > > > > 118 > > 119 /* > > 120 * Automatically generated definitions for system registers, the > > 121 * manual encodings below are in the process of being converted to > > 122 * come from here. The header relies on the definition of sys_reg() > > 123 * earlier in this file. > > 124 */ > > > 125 #include "generated/asm/sysreg.h" > > 126 > > > > --- > > 0-DAY CI Kernel Test Service > > https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org -- Best Regards Masahiro Yamada
Powered by blists - more mailing lists