Message ID | 20231205-objdump_reformat-awk-handle-llvm-objdump-bad_expr-v1-1-b4a74f39396f@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:bcd1:0:b0:403:3b70:6f57 with SMTP id r17csp3670393vqy; Tue, 5 Dec 2023 11:53:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IG8ERZmqZimjQ5Ye2hxvaVUI0O7U4cKB6brXOih2VqZtkDf3sJCJltxRmLWECRtJQcTpDS5 X-Received: by 2002:a05:6a20:7f95:b0:18f:97c:6162 with SMTP id d21-20020a056a207f9500b0018f097c6162mr7996287pzj.95.1701806009905; Tue, 05 Dec 2023 11:53:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701806009; cv=none; d=google.com; s=arc-20160816; b=ZHdKKi1nBTkqGScwdjuYWe06qbO6UM26mf5rrt0SkYyyhyfhuTGnfVemiNJZ3EQszF QiE9HssRLukEsPs/LPVc2LpUYArPfBEji9gvYw5p4JkvsYONHLV+Imbxauim9Y2qjAXy djG3vQ0TWhnoRp7Bk8XaXFC3iB0oynzT/PgNGUc5zaWy4AmyW/ZikNCiA90XyikmLw/T 4G/XnWrGHlLeuk4jJcshKdMzaJwqcLDFks2tjqte6aRg1tcV0951d6SFd4RehE66a1mA cJLka69Ruy0ztA4JEiakZ7BpyC/GawatvhSlK1DfKpl/Ih1sThhtH/YOGjq5o38x+5FB y3Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=HpHrSd3j70O99WmA71JaQ4ZF4XdmbwvyuXdi3EIwvdo=; fh=R5FJtXIHcrDMvXG/Tydt+mgSLjbmVJwOboV7IQgHINg=; b=V+Spha+EacN5FvVb/Z0S+/VdN6Qdrb8+7xm+OLek5XnvJjbmYI0DsxhOTFeF+7grxL kZH3nJX++9MEFFiQOly1naGN/SxXw2Q/BJNWS3Tw7iWhbq1EDWpM4JNpCKY4oCY0+ryZ j0jV4KzTR7TWAz9CS6jQtMwDkrift/wkyDwE+SuRP9JvGK/cOrxgfiM8DJ+XJ+UaEm4G 5OKTSOw0Mhf9/GQ8xBftqe+wn4iGD7Vc544C05nlSv1g/4vtRwne0DFdTJSM/e0YyA69 30VhodaOZasnMVNyzZvKODLTfCyIfewXGdZ0nmtCQDzv0OQ4RwvYOGOq7Malum5T3/bq umig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rZl2VeTY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from agentk.vger.email (agentk.vger.email. [2620:137:e000::3:2]) by mx.google.com with ESMTPS id cf6-20020a056a02084600b0057d7cff25b8si5221753pgb.198.2023.12.05.11.53.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 11:53:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) client-ip=2620:137:e000::3:2; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=rZl2VeTY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:2 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id ED37F80ABDF7; Tue, 5 Dec 2023 11:53:26 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231313AbjLETxK (ORCPT <rfc822;chrisfriedt@gmail.com> + 99 others); Tue, 5 Dec 2023 14:53:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229483AbjLETxK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 5 Dec 2023 14:53:10 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5AE23A5 for <linux-kernel@vger.kernel.org>; Tue, 5 Dec 2023 11:53:16 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7299FC433C7; Tue, 5 Dec 2023 19:53:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1701805996; bh=5bILRm/voPLjGTGQ/2zk5RoYBOPSzOEdtIPbiV7rR0M=; h=From:Date:Subject:To:Cc:From; b=rZl2VeTYSyv0nFgj+9bbl3iP7V9JuPOrOv3FngmiP8rmM/cmIPfZO4ZVt5HMqze2a wpPLxbChLvQZeb8H/r8AKrB/henHwRHiuygWU90/qwrPmQ/3SEOzwQlcaUblDCcdhA DroFvHKIO20pJloDs+TkUx5xi/I6Rs83ja3ECGJBSKzWmnkiPTAhaDGcuJpVNE4QFH NkxGjxBe/ganelNIOLJST+/RadhGxN2eQbFPd2qzbZ8/igHqdJZThmV3O1JysdfHbH 5Q+Ut/CzvDRcy3NJfe32z7PGITCI22ZjzD7qCAZ14duhfswBUDdx/AyzAG+NFojt0P NOpDjKnvax1/w== From: Nathan Chancellor <nathan@kernel.org> Date: Tue, 05 Dec 2023 12:53:08 -0700 Subject: [PATCH] x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20231205-objdump_reformat-awk-handle-llvm-objdump-bad_expr-v1-1-b4a74f39396f@kernel.org> X-B4-Tracking: v=1; b=H4sIAKN/b2UC/zWN2wrCMBAFf6XsswtptHj5FZGyaVaNJk3YaC2U/ ruL4OPAnDkLVJbAFU7NAsJTqCGPCu2mgeFO440xeGWwxm5bazrM7uHfqfTC1yyJXkifJ6rpI2O MU/oL6Mj3PBfBI+93g7dkDq4D7Radhvn3eb6s6xengL9GgwAAAA== To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org Cc: mhiramat@kernel.org, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, patches@lists.linux.dev, Nathan Chancellor <nathan@kernel.org> X-Mailer: b4 0.13-dev X-Developer-Signature: v=1; a=openpgp-sha256; l=1989; i=nathan@kernel.org; h=from:subject:message-id; bh=5bILRm/voPLjGTGQ/2zk5RoYBOPSzOEdtIPbiV7rR0M=; b=owGbwMvMwCUmm602sfCA1DTG02pJDKn59avvh/y0Yp8yseFB/C75KbV3D9tXvBTYeTTDb7/fp zXbeDniO0pZGMS4GGTFFFmqH6seNzScc5bxxqlJMHNYmUCGMHBxCsBEck8z/M9zP1Yfdo//ucHt O2ej3JYve8fS/WF/v3/gralT9/3hjjvCyPDadKqcXrDFjZd85To3Dwjf2RUm8XyT7/wDKrPmnDm zaD0/AA== X-Developer-Key: i=nathan@kernel.org; a=openpgp; fpr=2437CB76E544CB6AB3D9DFD399739260CB6CB716 X-Spam-Status: No, score=-1.2 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 05 Dec 2023 11:53:27 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1784472938959962618 X-GMAIL-MSGID: 1784472938959962618 |
Series |
x86/tools: objdump_reformat.awk: Skip bad instructions from llvm-objdump
|
|
Commit Message
Nathan Chancellor
Dec. 5, 2023, 7:53 p.m. UTC
When running the instruction decoder selftest with LLVM=1 +
CONFIG_PVH=y, there is a series of warnings:
arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this.
arch/x86/tools/insn_decoder_test: warning: ffffffff81000050 ea <unknown>
arch/x86/tools/insn_decoder_test: warning: objdump says 1 bytes, but insn_get_length() says 7
arch/x86/tools/insn_decoder_test: warning: Decoded and checked 7214721 instructions with 1 failures
GNU objdump outputs "(bad)" instead of "<unknown>", which is already
handled in the bad_expr regex, so there is no warning.
$ objdump -d arch/x86/platform/pvh/head.o | grep -E '50:\s+ea'
50: ea (bad)
$ llvm-objdump -d arch/x86/platform/pvh/head.o | grep -E '50:\s+ea'
50: ea <unknown>
Add "<unknown>" to the bad_expr regex to clear up the warning, allowing
the instruction decoder selftest to fully pass with llvm-objdump.
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
arch/x86/tools/objdump_reformat.awk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
---
base-commit: 5225952d74d43e4c054731c74b8afd700b23a94a
change-id: 20231205-objdump_reformat-awk-handle-llvm-objdump-bad_expr-9e74cd2a08b5
Best regards,
Comments
Ping? I am still seeing this issue. On Tue, Dec 05, 2023 at 12:53:08PM -0700, Nathan Chancellor wrote: > When running the instruction decoder selftest with LLVM=1 + > CONFIG_PVH=y, there is a series of warnings: > > arch/x86/tools/insn_decoder_test: warning: Found an x86 instruction decoder bug, please report this. > arch/x86/tools/insn_decoder_test: warning: ffffffff81000050 ea <unknown> > arch/x86/tools/insn_decoder_test: warning: objdump says 1 bytes, but insn_get_length() says 7 > arch/x86/tools/insn_decoder_test: warning: Decoded and checked 7214721 instructions with 1 failures > > GNU objdump outputs "(bad)" instead of "<unknown>", which is already > handled in the bad_expr regex, so there is no warning. > > $ objdump -d arch/x86/platform/pvh/head.o | grep -E '50:\s+ea' > 50: ea (bad) > > $ llvm-objdump -d arch/x86/platform/pvh/head.o | grep -E '50:\s+ea' > 50: ea <unknown> > > Add "<unknown>" to the bad_expr regex to clear up the warning, allowing > the instruction decoder selftest to fully pass with llvm-objdump. > > Signed-off-by: Nathan Chancellor <nathan@kernel.org> > --- > arch/x86/tools/objdump_reformat.awk | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/tools/objdump_reformat.awk b/arch/x86/tools/objdump_reformat.awk > index a4120d907277..20b08a6c4d33 100644 > --- a/arch/x86/tools/objdump_reformat.awk > +++ b/arch/x86/tools/objdump_reformat.awk > @@ -11,7 +11,7 @@ BEGIN { > prev_addr = "" > prev_hex = "" > prev_mnemonic = "" > - bad_expr = "(\\(bad\\)|^rex|^.byte|^rep(z|nz)$|^lock$|^es$|^cs$|^ss$|^ds$|^fs$|^gs$|^data(16|32)$|^addr(16|32|64))" > + bad_expr = "(\\(bad\\)|<unknown>|^rex|^.byte|^rep(z|nz)$|^lock$|^es$|^cs$|^ss$|^ds$|^fs$|^gs$|^data(16|32)$|^addr(16|32|64))" > fwait_expr = "^9b[ \t]*fwait" > fwait_str="9b\tfwait" > } > > --- > base-commit: 5225952d74d43e4c054731c74b8afd700b23a94a > change-id: 20231205-objdump_reformat-awk-handle-llvm-objdump-bad_expr-9e74cd2a08b5 > > Best regards, > -- > Nathan Chancellor <nathan@kernel.org> > >
On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote:
> Ping? I am still seeing this issue.
Does this need a Fixes tag and needs to go to Linus now or are you fine
with 6.8-rc0?
I.e., the answer probably depends on what kernels you're running the
llvm tests...
On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote: > On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote: > > Ping? I am still seeing this issue. > > Does this need a Fixes tag and needs to go to Linus now or are you fine > with 6.8-rc0? This is only needed due to the recent changes from Sam and myself in x86/build, so no need to rush it to Linus. I just wanted to make sure it was not lost before the chaos of the merge window. Cheers, Nathan
On Wed, Jan 03, 2024 at 01:55:06PM -0700, Nathan Chancellor wrote: > On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote: > > On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote: > > > Ping? I am still seeing this issue. > > > > Does this need a Fixes tag and needs to go to Linus now or are you fine > > with 6.8-rc0? > > This is only needed due to the recent changes from Sam and myself in > x86/build I don't understand: those three commits seem unrelated to LLVM objdump outputting "<unknown>". Or are you saying that you've *started* running the insn decoder selftest with llvm's objdump and those three commits are addressing differences in the output and this outstanding commit is needed too for the bad opcode case? Thx.
On Wed, Jan 03, 2024 at 10:26:16PM +0100, Borislav Petkov wrote: > On Wed, Jan 03, 2024 at 01:55:06PM -0700, Nathan Chancellor wrote: > > On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote: > > > On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote: > > > > Ping? I am still seeing this issue. > > > > > > Does this need a Fixes tag and needs to go to Linus now or are you fine > > > with 6.8-rc0? > > > > This is only needed due to the recent changes from Sam and myself in > > x86/build > > I don't understand: those three commits seem unrelated to LLVM objdump > outputting "<unknown>". > > Or are you saying that you've *started* running the insn decoder selftest > with llvm's objdump and those three commits are addressing differences > in the output and this outstanding commit is needed too for the bad > opcode case? Prior to commit 5225952d74d4 ("x86/tools: Remove chkobjdump.awk"), the insn decoder selftest would not actually run with llvm-objdump altogether because chkobjdump.awk would fail (because it was only written for GNU objdump). The two commits prior to 5225952d74d4 were cleaning up differences between the output of each objdump implementations and this change should have been a part of that work as well, I just did not build enough configurations to see it. Hopefully that clears things up. Cheers, Nathan
On Wed, Jan 03, 2024 at 02:48:09PM -0700, Nathan Chancellor wrote: > On Wed, Jan 03, 2024 at 10:26:16PM +0100, Borislav Petkov wrote: > > On Wed, Jan 03, 2024 at 01:55:06PM -0700, Nathan Chancellor wrote: > > > On Wed, Jan 03, 2024 at 07:18:52PM +0100, Borislav Petkov wrote: > > > > On Wed, Jan 03, 2024 at 11:15:42AM -0700, Nathan Chancellor wrote: > > > > > Ping? I am still seeing this issue. > > > > > > > > Does this need a Fixes tag and needs to go to Linus now or are you fine > > > > with 6.8-rc0? > > > > > > This is only needed due to the recent changes from Sam and myself in > > > x86/build > > > > I don't understand: those three commits seem unrelated to LLVM objdump > > outputting "<unknown>". > > > > Or are you saying that you've *started* running the insn decoder selftest > > with llvm's objdump and those three commits are addressing differences > > in the output and this outstanding commit is needed too for the bad > > opcode case? > > Prior to commit 5225952d74d4 ("x86/tools: Remove chkobjdump.awk"), the > insn decoder selftest would not actually run with llvm-objdump > altogether because chkobjdump.awk would fail (because it was only > written for GNU objdump). The two commits prior to 5225952d74d4 were > cleaning up differences between the output of each objdump > implementations and this change should have been a part of that work as > well, I just did not build enough configurations to see it. Hopefully > that clears things up. For the record, this explanation really should have been in the commit message of 5225952d74d4 but I guess I was not thinking at the time. Cheers, Nathan
On Wed, Jan 03, 2024 at 02:51:19PM -0700, Nathan Chancellor wrote: > For the record, this explanation really should have been in the commit > message of 5225952d74d4 but I guess I was not thinking at the time. That's fine - we have the Link tag. Lemme refer to that thread and we're good. Thx.
diff --git a/arch/x86/tools/objdump_reformat.awk b/arch/x86/tools/objdump_reformat.awk index a4120d907277..20b08a6c4d33 100644 --- a/arch/x86/tools/objdump_reformat.awk +++ b/arch/x86/tools/objdump_reformat.awk @@ -11,7 +11,7 @@ BEGIN { prev_addr = "" prev_hex = "" prev_mnemonic = "" - bad_expr = "(\\(bad\\)|^rex|^.byte|^rep(z|nz)$|^lock$|^es$|^cs$|^ss$|^ds$|^fs$|^gs$|^data(16|32)$|^addr(16|32|64))" + bad_expr = "(\\(bad\\)|<unknown>|^rex|^.byte|^rep(z|nz)$|^lock$|^es$|^cs$|^ss$|^ds$|^fs$|^gs$|^data(16|32)$|^addr(16|32|64))" fwait_expr = "^9b[ \t]*fwait" fwait_str="9b\tfwait" }