[jimc:dd-fix-2g] BUILD REGRESSION 664531695395972a1684dbc3604731db280b479e

[jim.cromie at gmail.com]

On Tue, Jun 13, 2023 at 11:43 AM <jim.cromie at 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 at 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 at 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 at 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.