public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Tom de Vries <tdevries@suse.de>
To: "Metzger, Markus T" <markus.t.metzger@intel.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: [PATCH] [gdb/testsuite] Add xfail in gdb.python/py-record-btrace.exp
Date: Tue, 14 Feb 2023 11:59:06 +0100	[thread overview]
Message-ID: <2bfa0573-bd7c-5dd6-6fea-f4837c4eeb66@suse.de> (raw)
In-Reply-To: <DM8PR11MB5749303396B044638563E4C3DEDD9@DM8PR11MB5749.namprd11.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

[ was: Re: [PATCH] [gdb/testsuite] Add have_linux_btrace_bug ]
On 2/13/23 20:17, Metzger, Markus T wrote:
> Hello Tom,
> 
>> The linux kernel commit 670638477aed ("perf/x86/intel/pt: Opportunistically
>> use single range output mode"), added in version v5.5.0 had a bug that was
>> fixed by commit ce0d998be927 ("perf/x86/intel/pt: Fix sampling using
>> single range output") in version 6.1.0.
>>
>> The bug manifested for intel microarchitectures Rocket Lake, Raptor Lake and
>> Alder Lake.
> 
> Actually, it's a h/w bug that got exposed by using single-range output.  It affects
> Core processors starting from Ice Lake and it only affects Processor Trace.  Also,
> it is only exposed by the py-record-btrace test, which does a lot of single-stepping.
> 
> It might be better to just add an XFAIL for that one test.  I'm not sure if maintaining
> a processor list makes sense.  The kernel patch disables single-range for > 1 page
> for all processors and does not try to maintain a list of affected processors.  We might
> want to do the same in GDB and either disable that test for kernels between 5.5 and
> 6.1, or setup an XFAIL.
> 

I've gone with the XFAIL, see attached patch.  WDYT?

> The Branch Trace Store issue you found seems to affect all btrace tests on ADL
> E-cores.  This is a different issue.  I can reproduce it and I am currently debugging it.

I see, ack, thanks for the update.

- Tom


[-- Attachment #2: 0001-gdb-testsuite-Add-xfail-in-gdb.python-py-record-btra.patch --]
[-- Type: text/x-patch, Size: 3583 bytes --]

From 99ebac02397f19bc16cad6a6fef7828fbc716803 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 13 Feb 2023 18:27:17 +0100
Subject: [PATCH] [gdb/testsuite] Add xfail in gdb.python/py-record-btrace.exp

There's a HW bug affecting Processor Trace on some Intel processors
(Ice Lake to Raptor Lake microarchitectures).

The bug was exposed by linux kernel commit 670638477aed
("perf/x86/intel/pt: Opportunistically use single range output mode"),
added in version v5.5.0, and was worked around by commit ce0d998be927
("perf/x86/intel/pt: Fix sampling using single range output") in version
6.1.0.

The bug manifests (on a Performance-core of an i7-1250U, an Alder Lake cpu) in
a single test-case:
...
(gdb) python insn = r.instruction_history^M
warning: Decode error (-20) at instruction 33 (offset = 0x3d6a, \
  pc = 0x400501): compressed return without call.^M
(gdb) FAIL: gdb.python/py-record-btrace.exp: prepare record: \
  python insn = r.instruction_history
...

Add a corresponding XFAIL.

Note that the i7-1250U has both Performance-cores and Efficient-cores, and on
an Efficient-Core the test-case runs without any problems, so if the testsuite
run is not pinned to a specific cpu, the test may either PASS or XFAIL.

Tested on x86_64-linux:
- openSUSE Leap 15.4 with linux kernel version 5.14.21
- openSUSE Tumbleweed with linux kernel version 6.1.8

PR testsuite/30075
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30075
---
 gdb/testsuite/gdb.python/py-record-btrace.exp | 44 ++++++++++++++++++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.python/py-record-btrace.exp b/gdb/testsuite/gdb.python/py-record-btrace.exp
index 555b70ae336..7deb157b73c 100644
--- a/gdb/testsuite/gdb.python/py-record-btrace.exp
+++ b/gdb/testsuite/gdb.python/py-record-btrace.exp
@@ -54,7 +54,49 @@ with_test_prefix "prepare record" {
     gdb_test "python print(r.method)" "btrace"
     gdb_test "python print(r.format)" "pt|bts"
     gdb_test "stepi 100" ".*"
-    gdb_test_no_output "python insn = r.instruction_history"
+
+    # There's a HW bug affecting Processor Trace on some Intel processors.
+    # The bug was exposed by linux kernel commit 670638477aed
+    # ("perf/x86/intel/pt: Opportunistically use single range output mode"),
+    # added in version v5.5.0, and was worked around by commit ce0d998be927
+    # ("perf/x86/intel/pt: Fix sampling using single range output") in version
+    # 6.1.0.  Detect the kernel version range for which the problem may
+    # manifest.
+    set have_xfail 0
+    set v [linux_kernel_version]
+    if { $v == {} } {
+	set have_xfail 0
+    } else {
+	set have_xfail \
+	    [expr [version_compare [list 5 5 0] <= $v] \
+		 && [version_compare $v < [list 6 1 0]]]
+    }
+    set xfail_re \
+	[join \
+	     [list \
+		  "warning: Decode error \\(.*\\) at instruction $decimal" \
+		  "\\(offset = $hex, pc = $hex\\):" \
+		  "compressed return without call\\."]]
+
+    set got_xfail 0
+    set cmd "python insn = r.instruction_history"
+    gdb_test_multiple $cmd "" {
+	-re "^[string_to_regexp $cmd]\r\n$::gdb_prompt $" {
+	    pass $gdb_test_name
+	}
+	-re -wrap "$xfail_re" {
+	    if { $have_xfail } {
+		xfail $gdb_test_name
+		set got_xfail 1
+	    } else {
+		fail $gdb_test_name
+	    }
+	}
+    }
+    if { $got_xfail } {
+	return
+    }
+
     gdb_test_no_output "python call = r.function_call_history"
     gdb_test_no_output "python i = insn\[0\]"
     gdb_test_no_output "python c = call\[0\]"

base-commit: 37d75d4552d6b4d292ffb4dee92329a449288375
-- 
2.35.3


  reply	other threads:[~2023-02-14 10:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 18:10 [PATCH] [gdb/testsuite] Add have_linux_btrace_bug Tom de Vries
2023-02-13 19:17 ` Metzger, Markus T
2023-02-14 10:59   ` Tom de Vries [this message]
2023-02-14 11:34     ` [PATCH] [gdb/testsuite] Add xfail in gdb.python/py-record-btrace.exp Metzger, Markus T

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=2bfa0573-bd7c-5dd6-6fea-f4837c4eeb66@suse.de \
    --to=tdevries@suse.de \
    --cc=gdb-patches@sourceware.org \
    --cc=markus.t.metzger@intel.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).