Re: [jimc:dd-fix-2g] BUILD REGRESSION 664531695395972a1684dbc3604731db280b479e
Trouble with __UNIQUE_ID Im getting an error which "shouldnt be possible", but is happening anyway. On Mon, Jun 12, 2023 at 2:55 PM kernel test robot <lkp@intel.com> wrote:
tree/branch: https://github.com/jimc/linux.git dd-fix-2g branch HEAD: 664531695395972a1684dbc3604731db280b479e drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers
Error/Warning: (recently discovered and may have been fixed)
hppa-linux-ld: drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user323'; drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined here include/drm/drm_print.h:421:9: error: implicit declaration of function '_dynamic_func_call_cls' [-Werror=implicit-function-declaration] riscv64-linux-ld: drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user305'; drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here riscv64-linux-ld: drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user374'; drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined here
Error/Warning ids grouped by kconfigs:
gcc_recent_errors |-- parisc-allyesconfig | `-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user323-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here |-- riscv-allyesconfig | |-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user305-drivers-gpu-drm-qxl-qxl_drv.o:(__dyndbg_class_users):first-defined-here | `-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user374-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here `-- x86_64-randconfig-a015-20230612 `-- include-drm-drm_print.h:error:implicit-declaration-of-function-_dynamic_func_call_cls
elapsed time: 756m
configs tested: 101 configs skipped: 6
tested configs: alpha allyesconfig gcc alpha defconfig gcc alpha randconfig-r022-20230612 gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r015-20230612 gcc arc randconfig-r043-20230612 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r046-20230612 clang arm64 allyesconfig gcc arm64 defconfig gcc csky defconfig gcc hexagon randconfig-r041-20230612 clang hexagon randconfig-r045-20230612 clang i386 allyesconfig gcc i386 buildonly-randconfig-r006-20230612 clang i386 debian-10.3 gcc i386 defconfig gcc i386 randconfig-i001-20230612 clang i386 randconfig-i002-20230612 clang i386 randconfig-i003-20230612 clang i386 randconfig-i004-20230612 clang i386 randconfig-i005-20230612 clang i386 randconfig-i006-20230612 clang i386 randconfig-i011-20230612 gcc i386 randconfig-i012-20230612 gcc i386 randconfig-i013-20230612 gcc i386 randconfig-i014-20230612 gcc i386 randconfig-i015-20230612 gcc i386 randconfig-i016-20230612 gcc i386 randconfig-r012-20230612 gcc i386 randconfig-r014-20230612 gcc i386 randconfig-r035-20230612 clang loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch buildonly-randconfig-r001-20230612 gcc loongarch defconfig gcc m68k allmodconfig gcc m68k allyesconfig gcc m68k buildonly-randconfig-r004-20230612 gcc m68k defconfig gcc mips allmodconfig gcc mips allyesconfig gcc mips randconfig-r001-20230612 gcc mips randconfig-r011-20230612 clang mips randconfig-r021-20230612 clang nios2 defconfig gcc nios2 randconfig-r032-20230612 gcc openrisc randconfig-r013-20230612 gcc openrisc randconfig-r024-20230612 gcc parisc allyesconfig gcc parisc defconfig gcc parisc randconfig-r004-20230612 gcc parisc64 defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc buildonly-randconfig-r003-20230612 gcc powerpc buildonly-randconfig-r005-20230612 gcc riscv allmodconfig gcc riscv allnoconfig gcc riscv allyesconfig gcc riscv defconfig gcc riscv randconfig-r003-20230612 clang riscv randconfig-r042-20230612 gcc riscv rv32_defconfig gcc s390 allmodconfig gcc s390 allyesconfig gcc s390 defconfig gcc s390 randconfig-r016-20230612 gcc s390 randconfig-r025-20230612 gcc s390 randconfig-r033-20230612 clang s390 randconfig-r044-20230612 gcc sh allmodconfig gcc sh randconfig-r002-20230612 gcc sh randconfig-r031-20230612 gcc sh randconfig-r036-20230612 gcc sparc allyesconfig gcc sparc defconfig gcc um i386_defconfig gcc um x86_64_defconfig gcc x86_64 allyesconfig gcc x86_64 buildonly-randconfig-r002-20230612 clang x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-a001-20230612 clang x86_64 randconfig-a002-20230612 clang x86_64 randconfig-a003-20230612 clang x86_64 randconfig-a004-20230612 clang x86_64 randconfig-a005-20230612 clang x86_64 randconfig-a006-20230612 clang x86_64 randconfig-a011-20230612 gcc x86_64 randconfig-a012-20230612 gcc x86_64 randconfig-a013-20230612 gcc x86_64 randconfig-a014-20230612 gcc x86_64 randconfig-a015-20230612 gcc x86_64 randconfig-a016-20230612 gcc x86_64 randconfig-r005-20230612 clang x86_64 rhel-8.3-rust clang x86_64 rhel-8.3 gcc
-- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
the source of the error is this: /** * DYNDBG_CLASSMAP_USE - refer to a classmap, DEFINEd elsewhere. * @_var: name of the exported classmap var * * This registers a module's use of another module's classmap defn, so * dyndbg can authorize "class DRM_CORE ..." >control commands upon * this module. */ #define DYNDBG_CLASSMAP_USE(_var) \ DYNDBG_CLASSMAP_USE_(_var, __UNIQUE_ID(ddebug_class_user)) #define DYNDBG_CLASSMAP_USE_(_var, _uname) \ extern struct ddebug_class_map _var; \ struct ddebug_class_user __used \ __section("__dyndbg_class_users") _uname = { \ .user_mod_name = KBUILD_MODNAME, \ .map = &_var, \ } I have reproduced this locally, with various errors, depending upon config and make.cross args heres one example: AR vmlinux.a LD vmlinux.o ld: ld: DWARF error: could not find abbrev number 7629 drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user303'; ld: DWARF error: could not find abbrev number 94 drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here make[1]: *** [/home/jimc/projects/lx/wk-suren/scripts/Makefile.vmlinux_o:61: vmlinux.o] Error 1 make: *** [/home/jimc/projects/lx/wk-suren/Makefile:1231: vmlinux_o] Error 2 [jimc@frodo rand-046-clang]$ grep -E 'QXL|GUD' .config CONFIG_DRM_QXL=y CONFIG_DRM_GUD=y searching that error gives results suggesting an LTO linker error, but some of the hits are quite old. note- despite the path, this is not a clang error - I get a different message (but still an error) when using make.cross COMPILER=clang is there something subtle (or obvious) wrong with my macro ?
On Tue, Jun 13, 2023 at 11:43 AM <jim.cromie@gmail.com> wrote:
Trouble with __UNIQUE_ID
Im getting an error which "shouldnt be possible", but is happening anyway.
On Mon, Jun 12, 2023 at 2:55 PM kernel test robot <lkp@intel.com> wrote:
hppa-linux-ld: drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user323'; drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined here
riscv64-linux-ld: drivers/gpu/drm/gud/gud_drv.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user305'; drivers/gpu/drm/qxl/qxl_drv.o:(__dyndbg_class_users+0x0): first defined here riscv64-linux-ld: drivers/gpu/drm/nouveau/nouveau_drm.o:(__dyndbg_class_users+0x0): multiple definition of `__UNIQUE_ID_ddebug_class_user374'; drivers/gpu/drm/radeon/radeon_drv.o:(__dyndbg_class_users+0x0): first defined here
Error/Warning ids grouped by kconfigs:
gcc_recent_errors |-- parisc-allyesconfig | `-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user323-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here |-- riscv-allyesconfig | |-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user305-drivers-gpu-drm-qxl-qxl_drv.o:(__dyndbg_class_users):first-defined-here | `-- multiple-definition-of-__UNIQUE_ID_ddebug_class_user374-drivers-gpu-drm-radeon-radeon_drv.o:(__dyndbg_class_users):first-defined-here
the source of the error is this:
/** * DYNDBG_CLASSMAP_USE - refer to a classmap, DEFINEd elsewhere. * @_var: name of the exported classmap var * * This registers a module's use of another module's classmap defn, so * dyndbg can authorize "class DRM_CORE ..." >control commands upon * this module. */ #define DYNDBG_CLASSMAP_USE(_var) \ DYNDBG_CLASSMAP_USE_(_var, __UNIQUE_ID(ddebug_class_user)) #define DYNDBG_CLASSMAP_USE_(_var, _uname) \ extern struct ddebug_class_map _var; \ struct ddebug_class_user __used \ __section("__dyndbg_class_users") _uname = { \ .user_mod_name = KBUILD_MODNAME, \ .map = &_var, \ }
is there something subtle (or obvious) wrong with my macro ?
git log --grep __UNIQUE_ID led me to a significant hint, in: commit e9092d0d97961146655ce51f43850907d95f68c3 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon Apr 9 10:34:07 2018 -0700 Fix subtle macro variable shadowing in min_not_zero() .... [ That said, __UNIQUE_ID() itself has several issues that make it less than wonderful. In particular, the "uniqueness" has a fallback on the line number, which means that it's not actually unique in more complex cases if you don't build with gcc or clang (which have working unique counters that aren't tied to line numbers). That historical broken fallback also means that we have that pointless "prefix" argument that doesn't actually make much sense _except_ for the known-broken case. Oh well. ] [jimc@frodo wk-suren]$ ack 'define __UNIQUE_ID' include/linux/compiler-clang.h 11:#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) include/linux/compiler-gcc.h 42:#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) include/linux/compiler.h 182:# define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __LINE__) tools/testing/scatterlist/linux/mm.h 65:#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) that 3rd defn, using __LINE__ is what Linus was talking about. for a quick-&-dirty test, I moved the offending DYNDBG_CLASSMAP_USE() decls down a few lines, this made the linker errors go away. It doesnt feel like a robust solution, but Im going with it.
participants (1)
-
jim.cromie@gmail.com