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

[Masahiro Yamada <masahiroy@kernel.org>]

On Wed, Feb 10, 2021 at 5:06 PM Jessica Yu <jeyu@kernel.org> wrote:
>
> +++ Stephen Rothwell [10/02/21 08:50 +1100]:
> >Hi Jessica,
> >
> >On Tue, 9 Feb 2021 16:16:20 +0100 Jessica Yu <jeyu@kernel.org> 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




I will post two patches with some commit log
after some testing.
(one for gen_autoksyms.sh and the other for modpost).





-- 
Best Regards
Masahiro Yamada