[PATCH 1/2] nios2: remove libgcc for lshrdi3, ashldi3, ashrdi3, muldi3, and ucmpdi2

[PATCH 1/2] nios2: remove libgcc for lshrdi3, ashldi3, ashrdi3, muldi3, and ucmpdi2

[Dinh Nguyen]

Use the kernel's runtime support for lshrdi3, ashldi3, ashrdi3, muldi3,
and ucmpdi2.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 arch/nios2/Kconfig              | 5 +++++
 arch/nios2/kernel/nios2_ksyms.c | 5 -----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/nios2/Kconfig b/arch/nios2/Kconfig
index 9c0e6eaeb005c..9417bcf583957 100644
--- a/arch/nios2/Kconfig
+++ b/arch/nios2/Kconfig
@@ -14,6 +14,11 @@ config NIOS2
 	select GENERIC_CPU_DEVICES
 	select GENERIC_IRQ_PROBE
 	select GENERIC_IRQ_SHOW
+	select GENERIC_LIB_LSHRDI3
+	select GENERIC_LIB_ASHLDI3
+	select GENERIC_LIB_ASHRDI3
+	select GENERIC_LIB_MULDI3
+	select GENERIC_LIB_UCMPDI2
 	select HAVE_ARCH_TRACEHOOK
 	select HAVE_ARCH_KGDB
 	select HAVE_PAGE_SIZE_4KB
diff --git a/arch/nios2/kernel/nios2_ksyms.c b/arch/nios2/kernel/nios2_ksyms.c
index e8710a269b398..15a223cad84e1 100644
--- a/arch/nios2/kernel/nios2_ksyms.c
+++ b/arch/nios2/kernel/nios2_ksyms.c
@@ -37,9 +37,4 @@ DECLARE_EXPORT(__udivmoddi4);
 DECLARE_EXPORT(__udivsi3);
 DECLARE_EXPORT(__umoddi3);
 DECLARE_EXPORT(__umodsi3);
-DECLARE_EXPORT(__muldi3);
 DECLARE_EXPORT(__mulsi3);
-DECLARE_EXPORT(__ucmpdi2);
-DECLARE_EXPORT(__lshrdi3);
-DECLARE_EXPORT(__ashldi3);
-DECLARE_EXPORT(__ashrdi3);
-- 
2.42.0.411.g813d9a9188

[PATCH 2/2] nios2: remove 64-bit division

[Dinh Nguyen]

The NIOS2 is not a 64-bit platform, so there is no need to support
64-bit division. Remove moddi3, udivmoddi4, and umoddi3.

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
 arch/nios2/kernel/nios2_ksyms.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/nios2/kernel/nios2_ksyms.c b/arch/nios2/kernel/nios2_ksyms.c
index 15a223cad84e1..400d2b8158dae 100644
--- a/arch/nios2/kernel/nios2_ksyms.c
+++ b/arch/nios2/kernel/nios2_ksyms.c
@@ -31,10 +31,7 @@ EXPORT_SYMBOL(flush_icache_range);
 
 DECLARE_EXPORT(__gcc_bcmp);
 DECLARE_EXPORT(__divsi3);
-DECLARE_EXPORT(__moddi3);
 DECLARE_EXPORT(__modsi3);
-DECLARE_EXPORT(__udivmoddi4);
 DECLARE_EXPORT(__udivsi3);
-DECLARE_EXPORT(__umoddi3);
 DECLARE_EXPORT(__umodsi3);
 DECLARE_EXPORT(__mulsi3);
-- 
2.42.0.411.g813d9a9188

Re: [PATCH 2/2] nios2: remove 64-bit division

[Arnd Bergmann]

On Mon, Oct 19, 2026, at 18:50, Dinh Nguyen wrote:
> The NIOS2 is not a 64-bit platform, so there is no need to support
> 64-bit division. Remove moddi3, udivmoddi4, and umoddi3.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

Reviewed-by: Arnd Bergmann <arnd@arndb.de>

Did this pass allyesconfig and some randconfig tests to ensure that
there are no hidden 64-bit divisions that need to be converted to
div_u64() etc?

Re: [PATCH 1/2] nios2: remove libgcc for lshrdi3, ashldi3, ashrdi3, muldi3, and ucmpdi2

[Arnd Bergmann]

On Mon, Oct 19, 2026, at 18:50, Dinh Nguyen wrote:
> Use the kernel's runtime support for lshrdi3, ashldi3, ashrdi3, muldi3,
> and ucmpdi2.
>
> Suggested-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>

You still link against libgcc in addition to the in-kernel
copies of these functions. While this may work correctly depending
on the link order, what I had suggested here is to remove libgcc
entirely here:

diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
index f1ff4ce0f1a2..173588c31abf 100644
--- a/arch/nios2/Makefile
+++ b/arch/nios2/Makefile
@@ -19,8 +19,6 @@ UTS_SYSNAME = Linux
 
 export MMU
 
-LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
-
 KBUILD_AFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
 
 KBUILD_CFLAGS += -pipe -D__linux__ -D__ELF__
@@ -37,7 +35,7 @@ KBUILD_CFLAGS += -DUTS_SYSNAME=\"$(UTS_SYSNAME)\"
 KBUILD_CFLAGS += -fno-builtin
 KBUILD_CFLAGS += -G 0
 
-libs-y		+= arch/nios2/lib/ $(LIBGCC)
+libs-y		+= arch/nios2/lib/
 
 INSTALL_PATH ?= /tftpboot
 nios2-boot := arch/$(ARCH)/boot


I expect you'll have to copy a few functions from the last gcc release
into arch/nios2/lib/ to make this work, at least (a GPLv2 compatible
version of) libgcc/config/nios2/lib2-divmod.c but maybe more.

     Arnd

Re: [PATCH 1/2] nios2: remove libgcc for lshrdi3, ashldi3, ashrdi3, muldi3, and ucmpdi2

[Simon Schuster]

Hi,

thank you all for the patches and suggestions!

On Mon, Oct 19, 2026 at 11:20:56PM +0200, Arnd Bergmann wrote:
> diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
> index f1ff4ce0f1a2..173588c31abf 100644
> --- a/arch/nios2/Makefile
> +++ b/arch/nios2/Makefile
> @@ -19,8 +19,6 @@ UTS_SYSNAME = Linux
>  
>  export MMU
>  
> -LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
> -
>  KBUILD_AFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
>  
>  KBUILD_CFLAGS += -pipe -D__linux__ -D__ELF__
> @@ -37,7 +35,7 @@ KBUILD_CFLAGS += -DUTS_SYSNAME=\"$(UTS_SYSNAME)\"
>  KBUILD_CFLAGS += -fno-builtin
>  KBUILD_CFLAGS += -G 0
>  
> -libs-y		+= arch/nios2/lib/ $(LIBGCC)
> +libs-y		+= arch/nios2/lib/
>  
>  INSTALL_PATH ?= /tftpboot
>  nios2-boot := arch/$(ARCH)/boot
> 
> 
> I expect you'll have to copy a few functions from the last gcc release
> into arch/nios2/lib/ to make this work, at least (a GPLv2 compatible
> version of) libgcc/config/nios2/lib2-divmod.c but maybe more.

So I did test this with allyesconfig plus minimal hardware support
configured in nios2:

CONFIG_NIOS2_ARCH_REVISION=1
# CONFIG_NIOS2_HW_MUL_SUPPORT is not set
# CONFIG_NIOS2_HW_MULX_SUPPORT is not set
# CONFIG_NIOS2_HW_DIV_SUPPORT is not set
# CONFIG_NIOS2_FPU_SUPPORT is not set
# CONFIG_NIOS2_CI_SWAB_SUPPORT is not set
CONFIG_NIOS2_CI_SWAB_NO=0

I used gcc-14.4.0 as the reference; this is what I required to get
allyesconfig to link (apart from some requied -Wno-...'s, but thats
another story), and along with the typedefs from lib2-nios2.h:

diff --git i/arch/nios2/lib/Makefile w/arch/nios2/lib/Makefile
index 9d5bf1df520c1..28d6a78533ba1 100644
--- i/arch/nios2/lib/Makefile
+++ w/arch/nios2/lib/Makefile
@@ -7,3 +7,6 @@ lib-y += delay.o
 lib-y += memcpy.o
 lib-y += memmove.o
 lib-y += memset.o
+lib-y += lib2-divmod.o
+lib-y += lib2-mul.o
+lib-y += lib2-divtable.o

This seems to be the minimal set of runtime dependencies.

In particular, modpost wants (across various modules):
- symbol '__divsi3'
- symbol '__modsi3'
- symbol '__mulsi3'
- symbol '__udivsi3'
- symbol '__umodsi3'

Interesting enough, divtable is not explicitly exported but implicitly
linked via libgcc all the time. It seems to be required e.g. by lz4_compress:

> lz4_compress.c:(.text+0xaec): undefined reference to `__divsi3_table'

This makes me wonder a bit about the how and why of eliminating libgcc:
I fully understand that we are playing catchup with gcc/libgcc here;
when gcc decides to emit calls to a new lib, we have to export that as
modules might use it; but where is the difference between pulling it
from libgcc or from the kernel runtime? Longterm stability against
'disappearing' symbols?

So, for NIOS2, the situation is quite simple, as gcc is not exactly a
moving target any more, but what is the situation with other
architectures?

On a more practical note, while technically feasible, I'm not sure
whether we can actually vendor/copy directly from libgcc; I think all
code there is GPLv3 with Runtime Exception. (I'm not a lawyer yadayada),
but I guess direct reuse in that way is problematic, given that the
kernel is GPLv2 only? So I guess we would need to do a reimplementation?

Best regards
Simon

Re: [PATCH 1/2] nios2: remove libgcc for lshrdi3, ashldi3, ashrdi3, muldi3, and ucmpdi2

[Arnd Bergmann]

On Tue, Oct 20, 2026, at 10:56, Simon Schuster wrote:
> On Mon, Oct 19, 2026 at 11:20:56PM +0200, Arnd Bergmann wrote:
>> diff --git a/arch/nios2/Makefile b/arch/nios2/Makefile
>> index f1ff4ce0f1a2..173588c31abf 100644
>> --- a/arch/nios2/Makefile
>> +++ b/arch/nios2/Makefile
>> @@ -19,8 +19,6 @@ UTS_SYSNAME = Linux
>>  
>>  export MMU
>>  
>> -LIBGCC         := $(shell $(CC) $(KBUILD_CFLAGS) $(KCFLAGS) -print-libgcc-file-name)
>> -
>>  KBUILD_AFLAGS += -march=r$(CONFIG_NIOS2_ARCH_REVISION)
>>  
>>  KBUILD_CFLAGS += -pipe -D__linux__ -D__ELF__
>> @@ -37,7 +35,7 @@ KBUILD_CFLAGS += -DUTS_SYSNAME=\"$(UTS_SYSNAME)\"
>>  KBUILD_CFLAGS += -fno-builtin
>>  KBUILD_CFLAGS += -G 0
>>  
>> -libs-y		+= arch/nios2/lib/ $(LIBGCC)
>> +libs-y		+= arch/nios2/lib/
>>  
>>  INSTALL_PATH ?= /tftpboot
>>  nios2-boot := arch/$(ARCH)/boot
>> 
>> 
>> I expect you'll have to copy a few functions from the last gcc release
>> into arch/nios2/lib/ to make this work, at least (a GPLv2 compatible
>> version of) libgcc/config/nios2/lib2-divmod.c but maybe more.
>
> So I did test this with allyesconfig plus minimal hardware support
> configured in nios2:

>  lib-y += memmove.o
>  lib-y += memset.o
> +lib-y += lib2-divmod.o
> +lib-y += lib2-mul.o
> +lib-y += lib2-divtable.o
>
> This seems to be the minimal set of runtime dependencies.

Ok, very good.

> In particular, modpost wants (across various modules):
> - symbol '__divsi3'
> - symbol '__modsi3'
> - symbol '__mulsi3'
> - symbol '__udivsi3'
> - symbol '__umodsi3'
>
> Interesting enough, divtable is not explicitly exported but implicitly
> linked via libgcc all the time. It seems to be required e.g. by lz4_compress:
>
>> lz4_compress.c:(.text+0xaec): undefined reference to `__divsi3_table'

Is it just modules that are not in your normal configuration then?
It seems easy enough to add this one as well.

> This makes me wonder a bit about the how and why of eliminating libgcc:
> I fully understand that we are playing catchup with gcc/libgcc here;
> when gcc decides to emit calls to a new lib, we have to export that as
> modules might use it; but where is the difference between pulling it
> from libgcc or from the kernel runtime? Longterm stability against
> 'disappearing' symbols?

The underlying problem is that the kernel is its own special environment
that is neither a standard C library nor a 'freestanding' implementation
and only vaguely similar to a mix of the two. We need certain parts
of libgcc but for convenience we want to force a link failure if the
compiler ever generates calls into functions we explicitly avoid
in the kernel like 64-bit division and floating point.

> So, for NIOS2, the situation is quite simple, as gcc is not exactly a
> moving target any more, but what is the situation with other
> architectures?

It is very rare that libgcc adds a new requirement and we can usually
deal with it when that happens. Every new compiler version requires
some kernel changes and libgcc is not a big part of that.

> On a more practical note, while technically feasible, I'm not sure
> whether we can actually vendor/copy directly from libgcc; I think all
> code there is GPLv3 with Runtime Exception. (I'm not a lawyer yadayada),
> but I guess direct reuse in that way is problematic, given that the
> kernel is GPLv2 only? So I guess we would need to do a reimplementation?

Right, the easiest way would be if you can locate a downstream gcc
(or clang) fork from Altera or Codesourcery before it was merged,
if that still has GPLv2 or a more liberal license. Reimplementing
the functions otherwise is of course annoying.

Adding Chung-Lin Tang to Cc, they contributed the original files
to gcc back in 2013 and may know a copyright holder that can
provide a GPLv2 compatible copy.

I also found a similar implemention for m32r that was still
GPLv2, maybe that one works, see https://github.com/gcc-mirror/gcc/commit/38b2d07632#diff-4de4f3b573100be00cf40045c85faaca8ded1f13ef80df1822889cbd6ad639a8

      Arnd