On Tue, Jun 13, 2023 at 11:43 AM <jim.cromie@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx>
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.
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
