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