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