linux-kernel - Re: ld.lld: error: undefined symbol: _

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]

Message-ID: <Y4913gH2tvIED61P@dev-arch.thelio-3990X>
Date:   Tue, 6 Dec 2022 10:03:26 -0700
From:   Nathan Chancellor <nathan@...nel.org>
To:     Mikhail Zhilkin <csharper2005@...il.com>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        kernel test robot <lkp@...el.com>, llvm@...ts.linux.dev,
        oe-kbuild-all@...ts.linux.dev, linux-kernel@...r.kernel.org,
        NOGUCHI Hiroshi <drvlabo@...il.com>
Subject: Re: ld.lld: error: undefined symbol: __udivdi3

Hi Mikhail,

First and foremost, apologies for the delay in my response!

On Thu, Dec 01, 2022 at 09:39:22PM +0300, Mikhail Zhilkin wrote:
> Hi Miquèl, Nathan,
> 
> On 12/1/2022 7:13 PM, Miquel Raynal wrote:
> > Hi Nathan,
> >
> > nathan@...nel.org wrote on Thu, 1 Dec 2022 09:00:57 -0700:
> >
> >> On Thu, Dec 01, 2022 at 09:16:10AM +0100, Miquel Raynal wrote:
> >>> Hi Mikhail, Hiroshi,
> >>>
> >>> lkp@...el.com wrote on Thu, 1 Dec 2022 01:46:36 +0800:
> >>>
> >>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >>>> head:   01f856ae6d0ca5ad0505b79bf2d22d7ca439b2a1
> >>>> commit: 9b78ef0c7997052e9eaa0f7a4513d546fa17358c mtd: parsers: add support for Sercomm partitions
> >>>> date:   6 months ago
> >>>> config: mips-randconfig-r033-20221128
> >>>> compiler: clang version 16.0.0 (https://github.com/llvm/llvm-project 6e4cea55f0d1104408b26ac574566a0e4de48036)
> >>>> reproduce (this is a W=1 build):
> >>>>         wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> >>>>         chmod +x ~/bin/make.cross
> >>>>         # install mips cross compiling tool for clang build
> >>>>         # apt-get install binutils-mipsel-linux-gnu
> >>>>         # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9b78ef0c7997052e9eaa0f7a4513d546fa17358c
> >>>>         git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> >>>>         git fetch --no-tags linus master
> >>>>         git checkout 9b78ef0c7997052e9eaa0f7a4513d546fa17358c
> >>>>         # save the config file
> >>>>         mkdir build_dir && cp config build_dir/.config
> >>>>         COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=mips SHELL=/bin/bash
> >>>>
> >>>> If you fix the issue, kindly add following tag where applicable
> >>>> | Reported-by: kernel test robot <lkp@...el.com>
> >>>>
> >>>> All errors (new ones prefixed by >>):
> >>>>
> >>>>>> ld.lld: error: undefined symbol: __udivdi3
> >>>>    >>> referenced by scpart.c
> >>>>    >>>               mtd/parsers/scpart.o:(scpart_parse) in archive drivers/built-in.a
> >>>>
> >>> Can you please try to reproduce this with a mips toolchain as advised
> >>> and send a fix?
> >> For what it's worth, this is likely our bug:
> >>
> >> https://github.com/ClangBuiltLinux/linux/issues/1635
> >>
> >> It sounds like there are some merged LLVM patches that should help but I
> >> guess not based on this report...
> > Ah, yeah, thanks a lot for the share.
> >
> > Cheers, Miquèl
> 
> I could reproduce the issue and found that reference to __udivdi3
> appears in this function:
> 
> static uint32_t scpart_desc_is_valid(struct sc_part_desc *pdesc)
> {
>         return ((pdesc->part_id != 0xffffffffUL) &&
>                 (pdesc->part_offs != 0xffffffffUL) &&
>                 (pdesc->part_bytes != 0xffffffffUL));
> }
> 
> There is no LLVM compiler error if:
> 
> static uint32_t scpart_desc_is_valid(struct sc_part_desc *pdesc)
> {
>         return (0);
> }
> 
> Currently I have no ideas where does __udivdi3 come from, because
> there's no division here. Should I try to rewrite somehow the function
> to avoid the error?
> I would greatly appreciate any ideas.

I do not think it is that function that is causing the problem. Making
it return zero just causes the code generation to change enough to avoid
this issue.

Based on the previous analysis and reduction [1], LLVM is transforming
the for loop in scpart_scan_partmap() into division; you can verify this
by commenting it out some way then rebuilding and running 'readelf -s'
to look for __udivdi3.

Arnd suggested working around this problem by making offs a 32-bit type,
as it is already bounded by ->erasesize, which appears to be a 32-bit
value from what I can tell. Making a change like so appears to resolve
the issue for me but I am not sure if that has any other implications.

diff --git a/drivers/mtd/parsers/scpart.c b/drivers/mtd/parsers/scpart.c
index 02601bb33de4..6e5e11c37078 100644
--- a/drivers/mtd/parsers/scpart.c
+++ b/drivers/mtd/parsers/scpart.c
@@ -50,7 +50,7 @@ static int scpart_scan_partmap(struct mtd_info *master, loff_t partmap_offs,
 	int cnt = 0;
 	int res = 0;
 	int res2;
-	loff_t offs;
+	uint32_t offs;
 	size_t retlen;
 	struct sc_part_desc *pdesc = NULL;
 	struct sc_part_desc *tmpdesc;

[1]: https://github.com/ClangBuiltLinux/linux/issues/1635

Cheers,
Nathan