[PATCH] nios2: ksyms: Declare __mulsi3 export

[PATCH] nios2: ksyms: Declare __mulsi3 export

[Thomas Weißschuh]

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>
---
 arch/nios2/kernel/nios2_ksyms.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/nios2/kernel/nios2_ksyms.c b/arch/nios2/kernel/nios2_ksyms.c
index c40aa39e8658..e8710a269b39 100644
--- a/arch/nios2/kernel/nios2_ksyms.c
+++ b/arch/nios2/kernel/nios2_ksyms.c
@@ -38,6 +38,7 @@ DECLARE_EXPORT(__udivsi3);
 DECLARE_EXPORT(__umoddi3);
 DECLARE_EXPORT(__umodsi3);
 DECLARE_EXPORT(__muldi3);
+DECLARE_EXPORT(__mulsi3);
 DECLARE_EXPORT(__ucmpdi2);
 DECLARE_EXPORT(__lshrdi3);
 DECLARE_EXPORT(__ashldi3);

---
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
change-id: 20261019-nios2-mulsi3-13394f57e37b

Best regards,
--  
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

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
> 

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

[Vineet Gupta]

On 10/19/26 04: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.

And seems like ARC is the biggest offender, what a shame.

> * 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

It seems Palmer added those back in 2018 which ARC was still developed 
actively, I totally missed them.
I now have a patch to switch ARC to generic helpers for those.

> * 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

It seems in some of the old binaries I have, dw mmc driver was at some 
point calling 64/64 divide which eventually got fixed.
But agree as of today there are no callers of 64-bit div/mod. I will get 
rid of ?div*di* from ARC.


> 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

And a second patch gets rid of those. FWIW back in the day some ARCAngel 
board's HDD driver needed those. Crazy times.

> * 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

ARCv2 has hardware divide so these are not needed, but ARC700 doesn't 
and there's a ton of calls for those.

┌───────────┬───────┬───────────┐
│  routine  │ calls │ functions │
├───────────┼───────┼───────────┤
│ __udivsi3 │ 415   │ 238       │
├───────────┼───────┼───────────┤
│ __umodsi3 │ 203   │ 131       │
├───────────┼───────┼───────────┤
│ __divsi3  │ 77    │ 57        │
├───────────┼───────┼───────────┤
│ __modsi3  │ 41    │ 33        │
└───────────┴───────┴───────────┘

I can take a stab at providing the generic libgcc implementation in 
lib/* but I only expect the arches using libgcc version to switch.

Thx,
-Vineet

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

[Vineet Gupta]

On 10/31/26 16:57, Vineet Gupta wrote:
>> * 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
> ARCv2 has hardware divide so these are not needed, but ARC700 doesn't
> and there's a ton of calls for those.
>
> ┌───────────┬───────┬───────────┐
> │  routine  │ calls │ functions │
> ├───────────┼───────┼───────────┤
> │ __udivsi3 │ 415   │ 238       │
> ├───────────┼───────┼───────────┤
> │ __umodsi3 │ 203   │ 131       │
> ├───────────┼───────┼───────────┤
> │ __divsi3  │ 77    │ 57        │
> ├───────────┼───────┼───────────┤
> │ __modsi3  │ 41    │ 33        │
> └───────────┴───────┴───────────┘
>
> I can take a stab at providing the generic libgcc implementation in
> lib/* but I only expect the arches using libgcc version to switch.

It seems there 4 are always needed together or not at all.
Do we want 4 Kconfig gates or just one will suffice ?

Thx,
-Vineet

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

[Arnd Bergmann]

On Sun, Nov 1, 2026, at 01:26, Vineet Gupta wrote:
> On 10/31/26 16:57, Vineet Gupta wrote:

>>
>> ┌───────────┬───────┬───────────┐
>> │  routine  │ calls │ functions │
>> ├───────────┼───────┼───────────┤
>> │ __udivsi3 │ 415   │ 238       │
>> ├───────────┼───────┼───────────┤
>> │ __umodsi3 │ 203   │ 131       │
>> ├───────────┼───────┼───────────┤
>> │ __divsi3  │ 77    │ 57        │
>> ├───────────┼───────┼───────────┤
>> │ __modsi3  │ 41    │ 33        │
>> └───────────┴───────┴───────────┘
>>
>> I can take a stab at providing the generic libgcc implementation in
>> lib/* but I only expect the arches using libgcc version to switch.
>
> It seems there 4 are always needed together or not at all.
> Do we want 4 Kconfig gates or just one will suffice ?

Either way is fine for me. Simon did separate symbols in his
nios2 patch[1], and I don't mind staying with that version
unless someone else feels strongly about it.

I would however like to have separate patches to add lib/divmul.c
and lib/mulsi3.c, and then patches on top that start using these
from nios2 and arc.

     Arnd

[1] https://lore.kernel.org/all/20261030-nios2-remove-usage-of-libgcc-v1-3-4e341c66082e@siemens-energy.com/