From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29D6BECAAD3 for ; Fri, 2 Sep 2022 00:54:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 825F08D0013; Thu, 1 Sep 2022 20:54:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D58C8D0001; Thu, 1 Sep 2022 20:54:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69D838D0013; Thu, 1 Sep 2022 20:54:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5B79C8D0001 for ; Thu, 1 Sep 2022 20:54:22 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 3A2C11A01B2 for ; Fri, 2 Sep 2022 00:54:22 +0000 (UTC) X-FDA: 79865324364.27.6B0A5F2 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf24.hostedemail.com (Postfix) with ESMTP id 08AE8180061 for ; Fri, 2 Sep 2022 00:54:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662080061; x=1693616061; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=L3mRRBK1ngAjAxHn3yh88wqZwNaBV7sRHz6khPlLV7w=; b=k0aHuLVraHvS9Vqzu0KcF1l0qAvtZzr6/7HdknBlhljdfI0UwwKzzUeu fa8DMCfnWfehzfH6d8kaDI4cws6A9x6TcVsAsxG0kyWO+wGhyva3N8rF9 /4aYbGF4IlhjHc47qh6Yfq+Ho4FSfugjuFF5XW01fEf+NdyixX1q3TMG4 lfZsqXwlHqPUIDqhceL3EkBZZTPencBIywIJEWF6fVHNFEqe3hV2uip6d 49HlOydzZ0+RQMZ8RtD2EB/7p6V34RK5tkSlGzMnXunaUOaOKARjrZ0sR gZPMRx2gILC6+LvNmb/lTGnAQj5m6wbYU9YGgxj3gicB5zPH7d1ECpR1w w==; X-IronPort-AV: E=McAfee;i="6500,9779,10457"; a="275608518" X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="275608518" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 17:54:19 -0700 X-IronPort-AV: E=Sophos;i="5.93,281,1654585200"; d="scan'208";a="642650565" Received: from rongch2-mobl.ccr.corp.intel.com (HELO [10.254.211.18]) ([10.254.211.18]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2022 17:54:16 -0700 Subject: Re: [kbuild-all] Re: powerpc-linux-objdump: Warning: Unrecognized form: 0x23 To: Nick Desaulniers , Nathan Chancellor Cc: Christophe Leroy , kernel test robot , Kees Cook , "llvm@lists.linux.dev" , "kbuild-all@lists.01.org" , "linux-kernel@vger.kernel.org" , Arnd Bergmann , Masahiro Yamada , Andrew Morton , Linux Memory Management List References: <202208311414.4OPuYS9K-lkp@intel.com> <8d2c3aef-aa4f-1f4d-dc89-622554ffda31@intel.com> <9d77cb93-2eff-d87d-6554-1636d5e7d5ec@csgroup.eu> <0acfb209-a792-a47b-0261-9fb29824e4b9@intel.com> From: "Chen, Rong A" Message-ID: <4c6da74c-4dc1-796c-5f22-bdd075b23c2b@intel.com> Date: Fri, 2 Sep 2022 08:54:14 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662080061; a=rsa-sha256; cv=none; b=8h7HeKXfScXN3kG/gopPkud/9kcGUW59RZo3NCGRQvd8gOJTO9djvfBrgZcnn29reg4C8H 5kcZf1q47i63ZEwbrgWPiKul/AdwQYPa3hjLJf8onp2PvIOt+yYU9lIFyR6XGFG4ZX4CxK RGVmo17Ktx7C2Me0Gbo48MzyXqRO7pc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=k0aHuLVr; spf=pass (imf24.hostedemail.com: domain of rong.a.chen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=rong.a.chen@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662080061; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wldb4YRSAIIjnL+ABXXHVxH3sumU8oAsW2KfzyYJKKw=; b=B5zAsEzJfgN16VA2IVqzNjDXHKM2tzhPlL9tqtZ/0JuiUCrjAKkaIlx4FlRvQ0SDA1Rngg jJfeqGlJfcrqbfEcnu74SuUC+I8qYPCKpqz5Xk5mcNnC5I3oMNaY1awwIeqcLflnZrPoDt K3rO6G4NRf0LJ31ypCm1aZx7YhhwteI= X-Rspam-User: X-Stat-Signature: x6f8a31jfmspa1azek8c4nhhasfe4pgq X-Rspamd-Queue-Id: 08AE8180061 X-Rspamd-Server: rspam06 Authentication-Results: imf24.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=k0aHuLVr; spf=pass (imf24.hostedemail.com: domain of rong.a.chen@intel.com designates 192.55.52.136 as permitted sender) smtp.mailfrom=rong.a.chen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1662080060-39064 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 9/2/2022 1:04 AM, Nick Desaulniers wrote: > On Thu, Sep 1, 2022 at 9:55 AM Nathan Chancellor wrote: >> >> On Thu, Sep 01, 2022 at 01:52:42PM +0800, Chen, Rong A wrote: >>> >>> >>> On 9/1/2022 1:45 PM, Christophe Leroy wrote: >>>> >>>> >>>> Le 01/09/2022 à 06:59, Chen, Rong A a écrit : >>>>> >>>>> >>>>> On 9/1/2022 10:03 AM, Nathan Chancellor wrote: >>>>>> Hi Rong, >>>>>> >>>>>> On Thu, Sep 01, 2022 at 09:15:58AM +0800, Chen, Rong A wrote: >>>>>>> >>>>>>> >>>>>>> On 8/31/2022 11:40 PM, Nathan Chancellor wrote: >>>>>>>> On Wed, Aug 31, 2022 at 02:52:36PM +0800, kernel test robot wrote: >>>>>>>>> tree: >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>>>>>> master >>>>>>>>> head: dcf8e5633e2e69ad60b730ab5905608b756a032f >>>>>>>>> commit: f9b3cd24578401e7a392974b3353277286e49cee Kconfig.debug: >>>>>>>>> make DEBUG_INFO selectable from a choice >>>>>>>>> date: 5 months ago >>>>>>>>> config: powerpc-buildonly-randconfig-r003-20220830 >>>>>>>>> (https://download.01.org/0day-ci/archive/20220831/202208311414.4OPuYS9K-lkp@intel.com/config) >>>>>>>>> compiler: clang version 16.0.0 >>>>>>>>> (https://github.com/llvm/llvm-project >>>>>>>>> c7df82e4693c19e3fd2e25c83eb04d9deb7b7b59) >>>>>>>>> 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 powerpc cross compiling tool for clang build >>>>>>>>> # apt-get install binutils-powerpc-linux-gnu >>>>>>>>> # >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f9b3cd24578401e7a392974b3353277286e49cee >>>>>>>>> git remote add linus >>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >>>>>>>>> git fetch --no-tags linus master >>>>>>>>> git checkout f9b3cd24578401e7a392974b3353277286e49cee >>>>>>>>> # 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=powerpc SHELL=/bin/bash >>>>>>>>> >>>>>>>>> If you fix the issue, kindly add following tag where applicable >>>>>>>>> Reported-by: kernel test robot >>>>>>>>> >>>>>>>>> All warnings (new ones prefixed by >>): >>>>>>>>> >>>>>>>>>>> powerpc-linux-objdump: Warning: Unrecognized form: 0x23 >>>>>>>> >>>>>>>> Given this is clang 16.0.0 with >>>>>>>> CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y, which uses DWARF5 by >>>>>>>> default instead of DWARF4, it looks like older binutils not >>>>>>>> understanding DWARF5. What version of binutils is being used by the >>>>>>>> bot? >>>>>>> >>>>>>> Hi Nathan, >>>>>>> >>>>>>> We're using binutils v2.38.90.20220713-2 >>>>>>> >>>>>>> ||/ Name Version Architecture Description >>>>>>> +++-==============-==================-============-========================================== >>>>>>> ii binutils 2.38.90.20220713-2 amd64 GNU assembler, >>>>>>> linker and binary utilities >>>>>> >>>>>> Thanks for chiming in! This looks like the output of 'dpkg -l', right? I >>>>> >>>>> Hi Nathan, >>>>> >>>>> oh, yes, I misunderstood, it's not related to this package. >>>>> >>>>>> noticed on second glance that the tuple for the objdump warning above is >>>>>> 'powerpc-linux-', which leads me to believe that a kernel.org toolchain >>>>>> (or a self compiled one) is being used. I would expect the tuple to be >>>>>> 'powerpc-linux-gnu-' if Debian's package was being used. Is that >>>>>> possible? >>>>> >>>>> you are right, we used a self-compiled toolchain, we'll try the binutils >>>>> from debian package. >>>> >>>> Can you first tell us the version you are using ? >>>> >>>> powerpc-linux-objdump -v >>>> >>>> That will tell you the version. >>> >>> Hi Christophe, >>> >>> the version is v2.38: >>> >>> $ ./powerpc-linux-objdump -v >>> GNU objdump (GNU Binutils) 2.38 >>> Copyright (C) 2022 Free Software Foundation, Inc. >>> This program is free software; you may redistribute it under the terms of >>> the GNU General Public License version 3 or (at your option) any later >>> version. >>> This program has absolutely no warranty. >> >> Thanks! I did some research and it seems like this warning is expected >> with binutils older than 2.39. The warning appears to come from >> read_and_display_attr_value() in binutils/dwarf.c. 0x22 and 0x23 are >> DW_FORM_loclistx and DW_FORM_rnglistx, which were only recently >> supported in that function. >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=28981 >> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=19c26da69d68d5d863f37c06ad73ab6292d02ffa >> >> That change shipped in binutils 2.39. I am not really sure how we should >> work around this in the kernel, other than maybe requiring binutils >> 2.39+ for CONFIG_DEBUG_INFO_DWARF5. Unfortunately, that will not fix >> CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT when DWARF5 is the default >> version... > > I've been working on a series that will encode the default implicit > dwarf version based on compiler version check. Maybe that can be > extended/reused here once that lands? > https://lore.kernel.org/llvm/20220831184408.2778264-1-ndesaulniers@google.com/ > Series needs revision, but it's on the right track. > >> Alternatively, switching to llvm-objdump for clang builds >> would help :) I am not aware of any issues that would affect that switch >> for PowerPC: >> >> https://github.com/ClangBuiltLinux/linux/labels/%5BTOOL%5D%20llvm-objdump > > Oh, is 0day doing `make CC=clang` rather than `make LLVM=1`? Rong, > any chance we get 0day folks to test LLVM=1 for more architectures? > Ideally we'd test both, preferably LLVM=1 if we had to choose. Hi Nick, Thanks for your advice, yes, we are doing `make CC=clang`, we'll plan it recently. Best Regards, Rong Chen > >> >> Cheers, >> Nathan > > >