* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export
[not found] <20261019-nios2-mulsi3-v1-1-4fd75b1bacef@linutronix.de>
@ 2026-10-19 11:16 ` Arnd Bergmann
2026-10-19 14:34 ` Dinh Nguyen
0 siblings, 1 reply; 3+ messages in thread
From: Arnd Bergmann @ 2026-10-19 11:16 UTC (permalink / raw)
To: Thomas Weißschuh, Dinh Nguyen,
schuster.simon@siemens-energy.com, Ley Foon Tan
Cc: linux-kernel, kernel test robot, linux-snps-arc, linux-parisc,
linux-openrisc@vger.kernel.org
On Mon, Oct 19, 2026, at 11:49, Thomas Weißschuh wrote:
> GCC may emit libcalls to __mulsi3(). As modpost is not aware that this
> function is provided through the linked in libgcc, it fails:
>
> ERROR: modpost: kernel/locking/test-ww_mutex.ko: symbol '__mulsi3' undefined!
> ERROR: modpost: kernel/time/test_udelay.ko: symbol '__mulsi3' undefined!
> ERROR: modpost: kernel/resource_kunit.ko: symbol '__mulsi3' undefined!
> ERROR: modpost: fs/fuse/virtiofs.ko: symbol '__mulsi3' undefined!
> etc.
>
> Make sure modpost can see the symbol from libgcc.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202610171933.J4bFOfL8-lkp@intel.com/
> Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
The patch looks correct to me, but it would also be nice to not use
libgcc at all. What I see is that only arc, nios2, openrisc and
parisc still link against the toolchain-provided libgcc, everything
else uses the kernel's own runtime.
It's probably not even that hard to do right, here is what I found
is imported from libgcc.
* Generic library helper exists, can be enabled through Kconfig:
=== __lshrdi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
-> lib/lshrdi3.c
=== __ashldi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
-> lib/ashldi3.c
=== __ashrdi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
-> lib/ashrdi3.c
=== __cmpdi2 ===
arch/arc/kernel/arcksyms.c
-> lib/cmpdi2.c
=== __muldi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
-> lib/muldi3.c
=== __ucmpdi2 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
-> lib/ucmpdi2.c
* 64-bit division probably should not be provided on arc or
nios2 (and sparc32, which has a private copy).
parisc64 should get these from libgcc/libgcc2.c.
=== __divdi3 ===
arch/parisc/kernel/parisc_ksyms.c
=== __udivmoddi4 ===
arch/nios2/kernel/nios2_ksyms.c
=== __udivdi3 ===
arch/arc/kernel/arcksyms.c
arch/parisc/kernel/parisc_ksyms.c
=== __umoddi3 ===
arch/nios2/kernel/nios2_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
=== __moddi3 ===
arch/nios2/kernel/nios2_ksyms.c
arch/parisc/kernel/parisc_ksyms.c
* floating-point math should not be provided by kernel:
=== __divdf3 ===
arch/arc/kernel/arcksyms.c
=== __divsf3 ===
arch/arc/kernel/arcksyms.c
=== __fixunsdfsi ===
arch/arc/kernel/arcksyms.c
=== __floatunsidf ===
arch/arc/kernel/arcksyms.c
=== __floatunsisf ===
arch/arc/kernel/arcksyms.c
=== __muldf3 ===
arch/arc/kernel/arcksyms.c
* no generic implementation in kernel, need to copy from
libgcc/lib1funcs.S code:
=== __divsi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
-> arch/arm/lib/lib1funcs.S
arch/m68k/lib/divsi3.S
arch/microblaze/lib/divsi3.S
arch/xtensa/lib/divsi3.S
=== __modsi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
-> arch/m68k/lib/modsi3.S
arch/microblaze/lib/modsi3.S
arch/xtensa/lib/modsi3.S
=== __udivsi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
-> arch/arm/lib/lib1funcs.S
arch/m68k/lib/udivsi3.S
arch/microblaze/lib/udivsi3.S
arch/sh/lib/udivsi3.S
arch/xtensa/lib/udivsi3.S
=== __umodsi3 ===
arch/arc/kernel/arcksyms.c
arch/nios2/kernel/nios2_ksyms.c
arch/openrisc/kernel/or32_ksyms.c
-> arch/arm/lib/lib1funcs.S
arch/m68k/lib/umodsi3.S
arch/microblaze/lib/umodsi3.S
arch/xtensa/lib/umodsi3.S
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export
2026-10-19 11:16 ` [PATCH] nios2: ksyms: Declare __mulsi3 export Arnd Bergmann
@ 2026-10-19 14:34 ` Dinh Nguyen
2026-10-20 9:40 ` David Laight
0 siblings, 1 reply; 3+ messages in thread
From: Dinh Nguyen @ 2026-10-19 14:34 UTC (permalink / raw)
To: Arnd Bergmann, Thomas Weißschuh,
schuster.simon@siemens-energy.com, Ley Foon Tan
Cc: linux-kernel, kernel test robot, linux-snps-arc, linux-parisc,
linux-openrisc@vger.kernel.org
On 10/19/26 06:16, Arnd Bergmann wrote:
> On Mon, Oct 19, 2026, at 11:49, Thomas Weißschuh wrote:
>> GCC may emit libcalls to __mulsi3(). As modpost is not aware that this
>> function is provided through the linked in libgcc, it fails:
>>
>> ERROR: modpost: kernel/locking/test-ww_mutex.ko: symbol '__mulsi3' undefined!
>> ERROR: modpost: kernel/time/test_udelay.ko: symbol '__mulsi3' undefined!
>> ERROR: modpost: kernel/resource_kunit.ko: symbol '__mulsi3' undefined!
>> ERROR: modpost: fs/fuse/virtiofs.ko: symbol '__mulsi3' undefined!
>> etc.
>>
>> Make sure modpost can see the symbol from libgcc.
>>
>> Reported-by: kernel test robot <lkp@intel.com>
>> Closes:
>> https://lore.kernel.org/oe-kbuild-all/202610171933.J4bFOfL8-lkp@intel.com/
>> Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
>
> The patch looks correct to me, but it would also be nice to not use
> libgcc at all. What I see is that only arc, nios2, openrisc and
> parisc still link against the toolchain-provided libgcc, everything
> else uses the kernel's own runtime.
>
> It's probably not even that hard to do right, here is what I found
> is imported from libgcc.
>
Patch applied!
Thanks for the suggestion Arnd, I'll work to on the NIOS2.
Dinh
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export
2026-10-19 14:34 ` Dinh Nguyen
@ 2026-10-20 9:40 ` David Laight
0 siblings, 0 replies; 3+ messages in thread
From: David Laight @ 2026-10-20 9:40 UTC (permalink / raw)
To: Dinh Nguyen
Cc: Arnd Bergmann, Thomas Weißschuh,
schuster.simon@siemens-energy.com, Ley Foon Tan, linux-kernel,
kernel test robot, linux-snps-arc, linux-parisc,
linux-openrisc@vger.kernel.org
On Mon, 19 Oct 2026 09:34:42 -0500
Dinh Nguyen <dinguyen@kernel.org> wrote:
> On 10/19/26 06:16, Arnd Bergmann wrote:
> > On Mon, Oct 19, 2026, at 11:49, Thomas Weißschuh wrote:
> >> GCC may emit libcalls to __mulsi3(). As modpost is not aware that this
> >> function is provided through the linked in libgcc, it fails:
> >>
> >> ERROR: modpost: kernel/locking/test-ww_mutex.ko: symbol '__mulsi3' undefined!
> >> ERROR: modpost: kernel/time/test_udelay.ko: symbol '__mulsi3' undefined!
> >> ERROR: modpost: kernel/resource_kunit.ko: symbol '__mulsi3' undefined!
> >> ERROR: modpost: fs/fuse/virtiofs.ko: symbol '__mulsi3' undefined!
> >> etc.
> >>
> >> Make sure modpost can see the symbol from libgcc.
> >>
> >> Reported-by: kernel test robot <lkp@intel.com>
> >> Closes:
> >> https://lore.kernel.org/oe-kbuild-all/202610171933.J4bFOfL8-lkp@intel.com/
> >> Fixes: 2fc8483fdcde ("nios2: Build infrastructure")
> >> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> >
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
> >
> > The patch looks correct to me, but it would also be nice to not use
> > libgcc at all. What I see is that only arc, nios2, openrisc and
> > parisc still link against the toolchain-provided libgcc, everything
> > else uses the kernel's own runtime.
> >
> > It's probably not even that hard to do right, here is what I found
> > is imported from libgcc.
> >
> Patch applied!
>
> Thanks for the suggestion Arnd, I'll work to on the NIOS2.
Does the kernel support nios2 that don't have the optional multiply
instructions? (including the ones that generate the high 32 bits).
If the compiler knows they exist (it isn't the default) then it should
just use them.
The fpga almost certainly have plenty of 18x18 DSP multiplier blocks
than can be used - so the resources are there.
(The slow part of the multiply is actually the ripple adder that
generates the high 46 bits.)
David
>
> Dinh
>
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2026-10-20 9:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20261019-nios2-mulsi3-v1-1-4fd75b1bacef@linutronix.de>
2026-10-19 11:16 ` [PATCH] nios2: ksyms: Declare __mulsi3 export Arnd Bergmann
2026-10-19 14:34 ` Dinh Nguyen
2026-10-20 9:40 ` David Laight
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox