[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

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

[Simon Schuster]

On Tue, Oct 20, 2026 at 11:41:59AM +0200, Arnd Bergmann wrote:
> 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.

Hmm, makes sense. The question is to what degree we assume those
particular implementations in libgcc to not do bad things... But if we
do, what about something like that:

$ nios2-buildroot-linux-gnu-objcopy \
        --keep-global-symbol '__divsi3' \
        --keep-global-symbol '__modsi3' \
        --keep-global-symbol '__mulsi3' \
        --keep-global-symbol '__udivsi3' \
        --keep-global-symbol '__umodsi3' \
        --keep-global-symbol '__divsi3_table' \
        "$(nios2-buildroot-linux-gnu-gcc -print-libgcc-file-name)" /tmp/libgcc.a

$ nios2-buildroot-linux-gnu-nm /tmp/libgcc.a | grep '\sT\|D\s'
00000000 T __divsi3
00000088 T __modsi3
000000fc T __udivsi3
00000160 T __umodsi3
00000000 D __divsi3_table
00000000 T __mulsi3

Wouldn't that fulfil the requirement as well? Only "vetted"/trustworthy
symbols get exported/linked, while it is easy to add additional symbols
if the need arises? (If we gracefully ignore the downsides, such as some
degree of brittleness such as implicitly assuming that all
dependent symbols reside in the same file as they will be switched
to local, and the fact that this is a hack, and that we tie us more
closely to gcc on architectures using said "hack").

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

Nice find, m32c-lib2.c seems identical to the modern nios2 lib2-divmod.c
(save whitespace changes). This already covers:
__divsi3
__modsi3
__udivsi3
__umodsi3

Regarding __divsi3_table:

This basically seems to be an array of 16 x 16 (even though its
linearized into memory) that caches the result of row_index / column_idx
(with divisions by 0 being assigned to 0), so "reimplementation" should
be trivial.

Regarding __mulsi3:

The iq2000 target seems to have a GPLv2 implementation; slight
difference in declared datatypes (iq2000 uses unsigned, nios2 uses
signed, I'd need to think a bit more about this), but should generally
be viable.
https://github.com/gcc-mirror/gcc/blob/releases/gcc-4.2/gcc/config/iq2000/lib2extra-funcs.c

So we should probably be able to assemble a libgcc-free nios2 kernel
runtime without the risk of introducing new bugs in potential
reimplementations if desired.

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 14:31, Simon Schuster wrote:
> On Tue, Oct 20, 2026 at 11:41:59AM +0200, Arnd Bergmann wrote:

> Wouldn't that fulfil the requirement as well? Only "vetted"/trustworthy
> symbols get exported/linked, while it is easy to add additional symbols
> if the need arises? (If we gracefully ignore the downsides, such as some
> degree of brittleness such as implicitly assuming that all
> dependent symbols reside in the same file as they will be switched
> to local, and the fact that this is a hack, and that we tie us more
> closely to gcc on architectures using said "hack").

That would work, but it would add complexity rather than simplifying
the build system.  Generally speaking I'd always try to do whatever
the more common architectures do, unless there is a strong reason
for it.

>> 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
>
> Nice find, m32c-lib2.c seems identical to the modern nios2 lib2-divmod.c
> (save whitespace changes). This already covers:
> __divsi3
> __modsi3
> __udivsi3
> __umodsi3
>
> Regarding __divsi3_table:
>
> This basically seems to be an array of 16 x 16 (even though its
> linearized into memory) that caches the result of row_index / column_idx
> (with divisions by 0 being assigned to 0), so "reimplementation" should
> be trivial.
>
> Regarding __mulsi3:
>
> The iq2000 target seems to have a GPLv2 implementation; slight
> difference in declared datatypes (iq2000 uses unsigned, nios2 uses
> signed, I'd need to think a bit more about this), but should generally
> be viable.
> https://github.com/gcc-mirror/gcc/blob/releases/gcc-4.2/gcc/config/iq2000/lib2extra-funcs.c

I now found another copy that may be even closer to what you need in
https://git.openembedded.org/openembedded/tree/recipes/gcc/gcc-4.1.2/gcc-nios2.patch

> So we should probably be able to assemble a libgcc-free nios2 kernel
> runtime without the risk of introducing new bugs in potential
> reimplementations if desired.

That sounds great, yes. Can you add the C implementations to the
architecture-independent lib/ directory with corresponding
CONFIG_GENERIC_LIB_* symbols? That should help create the a
similar patch for arc and openrisc if we can motivate someone
to do that.

      Arnd