Re: [PATCH] nios2: ksyms: Declare __mulsi3 export

Re: [PATCH] nios2: ksyms: Declare __mulsi3 export

[Arnd Bergmann]

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

Re: [PATCH] nios2: ksyms: Declare __mulsi3 export

[Dinh Nguyen]

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

Re: [PATCH] nios2: ksyms: Declare __mulsi3 export

[David Laight]

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
>