From: "Chen, Rong A" <rong.a.chen@intel.com>
To: Nick Desaulniers <ndesaulniers@google.com>,
Nathan Chancellor <nathan@kernel.org>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>,
kernel test robot <lkp@intel.com>,
Kees Cook <keescook@chromium.org>,
"llvm@lists.linux.dev" <llvm@lists.linux.dev>,
"kbuild-all@lists.01.org" <kbuild-all@lists.01.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Masahiro Yamada <masahiroy@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [kbuild-all] Re: powerpc-linux-objdump: Warning: Unrecognized form: 0x23
Date: Fri, 2 Sep 2022 08:54:14 +0800 [thread overview]
Message-ID: <4c6da74c-4dc1-796c-5f22-bdd075b23c2b@intel.com> (raw)
In-Reply-To: <CAKwvOdmzuupyAMhy-jT3O=-PT36T01N4SXkCPz6Cv0CPsxkK3Q@mail.gmail.com>
On 9/2/2022 1:04 AM, Nick Desaulniers wrote:
> On Thu, Sep 1, 2022 at 9:55 AM Nathan Chancellor <nathan@kernel.org> 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 <lkp@intel.com>
>>>>>>>>>
>>>>>>>>> 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
>
>
>
next prev parent reply other threads:[~2022-09-02 0:54 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-31 6:52 kernel test robot
2022-08-31 15:40 ` Nathan Chancellor
2022-09-01 1:15 ` [kbuild-all] " Chen, Rong A
2022-09-01 2:03 ` Nathan Chancellor
2022-09-01 4:59 ` Chen, Rong A
2022-09-01 5:45 ` Christophe Leroy
2022-09-01 5:52 ` Chen, Rong A
2022-09-01 16:55 ` Nathan Chancellor
2022-09-01 17:04 ` Nick Desaulniers
2022-09-02 0:54 ` Chen, Rong A [this message]
2022-09-02 1:01 ` Philip Li
2022-09-01 5:44 ` Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c6da74c-4dc1-796c-5f22-bdd075b23c2b@intel.com \
--to=rong.a.chen@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=christophe.leroy@csgroup.eu \
--cc=kbuild-all@lists.01.org \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox