Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")

[Nathan Chancellor <natechancellor@gmail.com>]

On Wed, May 15, 2019 at 08:31:49AM +0200, Arnd Bergmann wrote:
> On Wed, May 15, 2019 at 7:04 AM Leon Romanovsky <leonro@mellanox.com> wrote:
> > On Tue, May 14, 2019 at 09:32:02PM -0300, Jason Gunthorpe wrote:
> > > On Tue, May 14, 2019 at 12:45:10PM -0700, Nathan Chancellor wrote:
> > > > Hi all,
> > > >
> > > > I checked the RDMA mailing list and trees and I haven't seen this
> > > > reported/fixed yet (forgive me if it has) but when building for arm32
> > > > with multi_v7_defconfig and the following configs (distilled from
> > > > allyesconfig):
> > > >
> > > > CONFIG_INFINIBAND=y
> > > > CONFIG_INFINIBAND_ON_DEMAND_PAGING=y
> > > > CONFIG_INFINIBAND_USER_ACCESS=y
> > > > CONFIG_MLX5_CORE=y
> > > > CONFIG_MLX5_INFINIBAND=y
> > > >
> > > > The following link time errors occur:
> > > >
> > > > arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/main.o: in function `mlx5_ib_alloc_dm':
> > > > main.c:(.text+0x60c): undefined reference to `__aeabi_uldivmod'
> > > > arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/cmd.o: in function `mlx5_cmd_alloc_sw_icm':
> > > > cmd.c:(.text+0x6d4): undefined reference to `__aeabi_uldivmod'
> > > > arm-linux-gnueabi-ld: drivers/infiniband/hw/mlx5/cmd.o: in function `mlx5_cmd_dealloc_sw_icm':
> > > > cmd.c:(.text+0x9ec): undefined reference to `__aeabi_uldivmod'
> > >
> > > Fengguang, I'm surprised that 0-day didn't report this earlier..
> >
> > I got many successful emails after I pushed this patch to 0-day testing.
> 
> The long division warnings can compiler specific, and depend on certain
> optimization options, as compilers can optimize out certain divisions and
> replace them with multiplications and/or shifts, or prove that they can be
> replaced with a 32-bit division. If this is a case that gcc manages to
> optimize but clang does not, it might be worth looking into whether an
> optimization can be added to clang, in addition to improving the source.
> 
>      Arnd

While I did run initially run into this with clang, the errors above are
with gcc (mainly to show this was going to be a universal problem and
not just something with clang).

Nathan