Hi John, Helge,
Could you test the attached patch please?
Again, I only tested compilation for this.
I do not have parisc64 hardware.
In my understanding, QEMU does not support hppa64.
I do not find a way to test parisc64.
Masahiro Yamada
On Sun, Sep 10, 2023 at 4:20 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> With a little more investigation,
> I found arch/parisc/kernel/parisc_ksyms.c
> is causing the issue.
>
> That file is a collection of EXPORT_SYMBOL
> of assembly code.
>
> I will take a closer look tomorrow.
>
>
>
>
>
>
>
>
>
>
>
> On Sun, Sep 10, 2023 at 2:20 AM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
> >
> > On Fri, Sep 8, 2023 at 7:02 AM John David Anglin <dave.anglin@xxxxxxxx> wrote:
> > >
> > > On 2023-09-05 7:59 p.m., John David Anglin wrote:
> > > > On 2023-09-05 5:57 p.m., John David Anglin wrote:
> > > >> I'll check ddb5cdbafaaa.
> > > > Similar fault with ddb5cdbafaaa:
> > > The alignment of the __kstrtab_ symbols in vmlinux seems wrong.
> >
> > __kstrtab_ symbols do not need alignment.
> >
> > They were not aligned at all
> > before ddb5cdbafaaa^.
> >
> >
> >
> > > I'm fairly certain that function
> > > references prefixed with P% on hppa64 need 8 byte alignment.
> >
> > Yeah.
> > In the following dump, all of __ksymtab_* are correctly 8-byte aligned.
> >
> >
> > >
> > > 81662: 0000000040ea4358 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_system[...]
> > > 81663: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_syst[...]
> > > 81664: 0000000040e8e830 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_system[...]
> > > 81665: 0000000040ea4365 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_static[...]
> > > 81666: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_stat[...]
> > > 81667: 0000000040ea1640 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_static[...]
> > > 81668: 0000000040ea437c 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_reset_[...]
> > > 81669: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_rese[...]
> > > 81670: 0000000040e8bbc0 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_reset_[...]
> > > 81671: 0000000040ea438a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_loops_[...]
> > > 81672: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_loop[...]
> > > 81673: 0000000040e86610 0 NOTYPE LOCAL DEFAULT 14 __ksymtab_loops_[...]
> > > 81674: 0000000040ea439a 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_uts_ns
> > > 81675: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_init[...]
> > > 81676: 0000000040e99180 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_init_uts_ns
> > > 81677: 0000000040ea43a6 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_name_t[...]
> > > 81678: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_name[...]
> > > 81679: 0000000040e9b340 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_name_t[...]
> > > 81680: 0000000040ea43b4 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_wait_f[...]
> > > 81681: 0000000040ea4748 0 NOTYPE LOCAL DEFAULT 16 __kstrtabns_wait[...]
> > > 81682: 0000000040ea3638 0 NOTYPE LOCAL DEFAULT 15 __ksymtab_wait_f[...]
> > > 81683: 0000000040ea43c7 0 NOTYPE LOCAL DEFAULT 16 __kstrtab_init_task
> > > [...]
> > >
> > > I'm not sure how we get symbols that aren't 8 byte aligned. The ".balign 4" directive
> > > in __KSYMTAB doesn't seem correct but it's not the whole problem.
> > >
> > > Dave
> > >
> > > --
> > > John David Anglin dave.anglin@xxxxxxxx
> > >
> >
> >
> > --
> > Best Regards
> > Masahiro Yamada
>
>
>
> --
> Best Regards
> Masahiro Yamada
--
Best Regards
Masahiro Yamada
From e473c9fa49801aea7c37d4cf19710d89ff358ab6 Mon Sep 17 00:00:00 2001
From: Masahiro Yamada <masahiroy@xxxxxxxxxx>
Date: Wed, 6 Sep 2023 03:46:57 +0900
Subject: [PATCH] linux/export: fix reference to exported functions for
parisc64
John David Anglin reported parisc has been broken since commit
ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost").
Like ia64, parisc64 uses a function descriptor. The function
references must be prefixed with P%.
Also, symbols prefixed $$ from the library have the symbol type
STT_LOPROC instead of STT_FUNC. They should be handled as functions
too.
Fixes: ddb5cdbafaaa ("kbuild: generate KSYMTAB entries by modpost")
Reported-by: John David Anglin <dave.anglin@xxxxxxxx>
Closes: https://lore.kernel.org/linux-parisc/1901598a-e11d-f7dd-a5d9-9a69d06e6b6e@xxxxxxxx/T/#u
Signed-off-by: Masahiro Yamada <masahiroy@xxxxxxxxxx>
---
include/linux/export-internal.h | 2 ++
scripts/mod/modpost.c | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/include/linux/export-internal.h b/include/linux/export-internal.h
index 1c849db953a5..45fca09b2319 100644
--- a/include/linux/export-internal.h
+++ b/include/linux/export-internal.h
@@ -52,6 +52,8 @@
#ifdef CONFIG_IA64
#define KSYM_FUNC(name) @fptr(name)
+#elif defined(CONFIG_PARISC) && defined(CONFIG_64BIT)
+#define KSYM_FUNC(name) P%name
#else
#define KSYM_FUNC(name) name
#endif
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 34a5386d444a..de499dce5265 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1228,6 +1228,15 @@ static void check_export_symbol(struct module *mod, struct elf_info *elf,
*/
s->is_func = (ELF_ST_TYPE(sym->st_info) == STT_FUNC);
+ /*
+ * For parisc64, symbols prefixed $$ from the library have the symbol type
+ * STT_LOPROC. They should be handled as functions too.
+ */
+ if (elf->hdr->e_ident[EI_CLASS] == ELFCLASS64 &&
+ elf->hdr->e_machine == EM_PARISC &&
+ ELF_ST_TYPE(sym->st_info) == STT_LOPROC)
+ s->is_func = true;
+
if (match(secname, PATTERNS(INIT_SECTIONS)))
warn("%s: %s: EXPORT_SYMBOL used for init symbol. Remove __init or EXPORT_SYMBOL.\n",
mod->name, name);
--
2.39.2
