Re: linux-next: build failure after merge of the modules tree

[Masahiro Yamada]

On Wed, Feb 10, 2021 at 5:37 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> On Wed, Feb 10, 2021 at 5:06 PM Jessica Yu <jeyu@xxxxxxxxxx> wrote:
> >
> > +++ Stephen Rothwell [10/02/21 08:50 +1100]:
> > >Hi Jessica,
> > >
> > >On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu <jeyu@xxxxxxxxxx> wrote:
> > >>
> > >> Hmm, these errors don't look like it's related to that particular commit. I was
> > >
> > >I found this commit by bisection and then tested by reverting it.
> > >
> > >Before this commit, CONFIG_TRIM_UNUSED_KSYMS would not be set in the
> > >allyesconfig build because CONFIG_UNUSED_SYMBOLS was set.  After this
> > >commit, CONFIG_TRIM_UNUSED_KSYMS will be set in the allyesconfig build.
> >
> > Ah, that makes sense then. I would get the error on powerpc whenever
> > CONFIG_TRIM_UNUSED_KSYMS was enabled.
> >
> > >> able to reproduce these weird autoksym errors even without any modules-next
> > >> patches applied, and on a clean v5.11-rc7 tree. To reproduce it,
> > >> CONFIG_TRIM_UNUSED_KSYMS needs to be enabled. I guess that's why we run into
> > >> these errors with allyesconfig. I used a gcc-7 ppc64le cross compiler and got
> > >> the same compiler warnings. It seems to not compile on powerpc properly because
> > >> it looks like some symbols have an extra dot "." prefix, for example in
> > >> kthread.o:
> > >>
> > >>     168: 0000000000000318    24 NOTYPE  GLOBAL DEFAULT    6 kthread_create_worker
> > >>     169: 0000000000001d90   104 FUNC    GLOBAL DEFAULT    1 .kthread_create_worker
> > >>     170: 0000000000000330    24 NOTYPE  GLOBAL DEFAULT    6 kthread_create_worker_on_cpu
> > >>     171: 0000000000001e00    88 FUNC    GLOBAL DEFAULT    1 .kthread_create_worker_on_cpu
> > >>     172: 0000000000000348    24 NOTYPE  GLOBAL DEFAULT    6 kthread_queue_work
> > >>     173: 0000000000001e60   228 FUNC    GLOBAL DEFAULT    1 .kthread_queue_work
> > >>
> > >> So I suppose this dot prefix is specific to powerpc. From the ppc64 elf abi docs:
> > >>
> > >>      Symbol names with a dot (.) prefix are reserved for holding entry point
> > >>      addresses. The value of a symbol named ".FN", if it exists, is the entry point
> > >>      of the function "FN".
> > >>
> > >> I guess the presence of the extra dot symbols is confusing
> > >> scripts/gen_autoksyms.sh, so we get the dot symbols in autoksyms.h, which the
> > >> preprocessor doesn't like. I am wondering how this was never caught until now
> > >> and also now curious if this feature was ever functional on powerpc..
> > >
> > >Which feature?
> >
> > Sorry, by "feature" I meant CONFIG_TRIM_UNUSED_KSYMS. This config
> > option was introduced around v4.7. If simply enabling it produces
> > these compilation errors I was wondering if it ever built properly on
> > powerpc.
> >
> > Thanks,
> >
> > Jessica
>
>
> Thanks for the report.
>
> I think the following will fix the issue,
> but modpost needs fixing too.
>
>
> diff --git a/scripts/gen_autoksyms.sh b/scripts/gen_autoksyms.sh
> index 16c0b2ddaa4c..996a7109167b 100755
> --- a/scripts/gen_autoksyms.sh
> +++ b/scripts/gen_autoksyms.sh
> @@ -44,7 +44,7 @@ sed 's/ko$/mod/' $modlist |
>  xargs -n1 sed -n -e '2{s/ /\n/g;/^$/!p;}' -- |
>  cat - "$ksym_wl" |
>  sort -u |
> -sed -e 's/\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
> +sed -e 's/^\.\{,1\}\(.*\)/#define __KSYM_\1 1/' >> "$output_file"
>
>  # Special case for modversions (see modpost.c)
>  if [ -n "$CONFIG_MODVERSIONS" ]; then
> m



After some more tests, I noticed the code above was not correct.
I still saw a lot of modpost errors.

ERROR: modpost: "_mcount" [arch/powerpc/oprofile/oprofile.ko] undefined!
ERROR: modpost: "._mcount" [arch/powerpc/oprofile/oprofile.ko] undefined!


I just posted a patch, which fixes the error as far as I tested.
https://patchwork.kernel.org/project/linux-kbuild/patch/20210211061416.3747231-1-masahiroy@xxxxxxxxxx/



-- 
Best Regards
Masahiro Yamada