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

["Arnd Bergmann" <arnd@arndb.de>]

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