Re: [PATCH 0/3] lib: Add software mul/div helpers and use them from nios2

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

On Fri, Oct 30, 2026, at 16:53, Simon Schuster wrote:
> Recently, there have been linking failures on nios2 regarding libgcc
> symbols that we reexport to modules (in particular __mulsi3 [0], and
> __divsi3_table [1]).
>
> In the resulting discussion, Arnd suggested [2] dropping the libgcc
> dependency altogether, as -- while specific functions might be fine --
> libgcc does not expect to run in a kernel-like freestanding environment.
>
> To this end, Dinh Nguyen was kind enough to locate and extract
> GPLv2-compliant versions of the software mul/div/mod and __gcc_bcmp
> functions required by nios2 gcc and integrate them into the kernel.
>
> As Arnd also suggested [3] that these might be helpful to other smaller
> architectures (such as arc or openrisc), I've further extracted them to
> lib/ with corresponding CONFIG_GENERIC_LIB_* options that allow
> selectively enabling and exporting these as required.
>
> The patch series compiles mostly^4 fine in a nios2 allyesconfig
> without modpost errors; a quick boot test on a regular build also
> completed successfully.

This looks very good to me overall, thanks for working on this.

Just a few minor things that stood out:

- I don't see a need to add the files under arch/ first and then
  move them to lib/, just start with the added files there

- I did not expect gccbcmp.c to be needed at all, the kernel
  should handle the string functions internally. If you do need it,
  there is of course no harm adding it, but probably need to
  build with -ffreestanding to prevent it from recursively
  ending up in bcmp()

> One aspect I'm not fully sure of is whether adding declarations for the
> new lib/ functions to include/linux/libgcc.h unconditionally in the last
> patch of this series is completely clean; but it matches how other
> "optional vendored" functions in libgcc.h seem to be handled.

That part is looks fine.

      Arnd