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