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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 16 May 2019 10:21:35 +0800
From:   Fengguang Wu <fengguang.wu@...el.com>
To:     Nathan Chancellor <natechancellor@...il.com>
Cc:     Arnd Bergmann <arnd@...db.de>,
        Leon Romanovsky <leonro@...lanox.com>,
        Jason Gunthorpe <jgg@...pe.ca>,
        "kbuild@...org" <kbuild@...org>,
        Ariel Levkovich <lariel@...lanox.com>,
        Eli Cohen <eli@...lanox.com>, Mark Bloch <markb@...lanox.com>,
        Doug Ledford <dledford@...hat.com>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Philip Li <philip.li@...el.com>,
        Rong Chen <rong.a.chen@...el.com>
Subject: Re: undefined reference to `__aeabi_uldivmod' after 25c13324d03d
 ("IB/mlx5: Add steering SW ICM device memory type")

CC current 0day kbuild test maintainers Philip and Rong. -fengguang

On Tue, May 14, 2019 at 11:49:18PM -0700, Nathan Chancellor wrote:
>On Wed, May 15, 2019 at 08:42:13AM +0200, Arnd Bergmann wrote:
>> On Wed, May 15, 2019 at 8:40 AM Nathan Chancellor
>> <natechancellor@...il.com> wrote:
>> > 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@...lanox.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.
>> >
>> > 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).
>>
>> Which gcc version did you use here? Anything particularly old or particularly
>> new? I think 0-day is on a fairly recent gcc-8, but not the latest gcc-9
>> release.
>
>8.2.0 it seems (I've been meaning to build from the 9.x branch though
>since it appears that Arch's arm-linux-gnueabi-gcc isn't going to get
>updated since it's in the AUR).
>