* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export [not found] <20261019-nios2-mulsi3-v1-1-4fd75b1bacef@linutronix.de> @ 2026-10-19 11:16 ` Arnd Bergmann 0 siblings, 0 replies; 6+ 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] 6+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export @ 2026-10-19 11:16 ` Arnd Bergmann 0 siblings, 0 replies; 6+ 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export 2026-10-19 11:16 ` Arnd Bergmann @ 2026-10-19 14:34 ` Dinh Nguyen -1 siblings, 0 replies; 6+ 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export @ 2026-10-19 14:34 ` Dinh Nguyen 0 siblings, 0 replies; 6+ 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] 6+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export 2026-10-19 14:34 ` Dinh Nguyen @ 2026-10-20 9:40 ` David Laight -1 siblings, 0 replies; 6+ 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 > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nios2: ksyms: Declare __mulsi3 export @ 2026-10-20 9:40 ` David Laight 0 siblings, 0 replies; 6+ 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] 6+ messages in thread
end of thread, other threads:[~2026-10-20 9:40 UTC | newest]
Thread overview: 6+ 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 11:16 ` Arnd Bergmann
2026-10-19 14:34 ` Dinh Nguyen
2026-10-19 14:34 ` Dinh Nguyen
2026-10-20 9:40 ` David Laight
2026-10-20 9:40 ` David Laight
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.