This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] btrace, testsuite: fix spurious gdb.btrace/tsx.exp fails
- From: Pedro Alves <palves at redhat dot com>
- To: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Fri, 18 Sep 2015 13:56:39 +0100
- Subject: Re: [PATCH] btrace, testsuite: fix spurious gdb.btrace/tsx.exp fails
- Authentication-results: sourceware.org; auth=none
- References: <1442565363-13628-1-git-send-email-markus dot t dot metzger at intel dot com> <55FBF91C dot 8070703 at redhat dot com> <A78C989F6D9628469189715575E55B23331BDB81 at IRSMSX104 dot ger dot corp dot intel dot com>
On 09/18/2015 01:12 PM, Metzger, Markus T wrote:
>> -----Original Message-----
>> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
>> owner@sourceware.org] On Behalf Of Pedro Alves
>> Sent: Friday, September 18, 2015 1:44 PM
>> To: Metzger, Markus T
>> Cc: gdb-patches@sourceware.org
>> Subject: Re: [PATCH] btrace, testsuite: fix spurious gdb.btrace/tsx.exp fails
>>
>> On 09/18/2015 09:36 AM, Markus Metzger wrote:
>>> If the atomic section in x86-tsx.S is aborted,
>>
>> When can that happen? Is it normal that the test sees this?
>
> A transaction can be aborted for various reasons. One such reason is an
> interrupt, which can happen at any time.
I was under the impression that the hardware or kernel would retry
the transaction and that that would be transparent to
userspace, but sounds like not then.
> This occurs very infrequently. After I saw this the first time, I had to re-run
> the test several dozen times to reproduce it again.
+gdb_test_multiple "record instruction-history" "speculation indication" {
+ -re "$abort_1.*$gdb_prompt $" {
+ pass "speculation indication: abort"
+ }
+ -re "$abort_2.*$gdb_prompt $" {
+ pass "speculation indication: abort"
+ }
+ -re "$begin_to_end.*$gdb_prompt $" {
+ pass "speculation indication: begin..end"
+ }
+}
Note this will cause ping-ponging of PASS messages, resulting
in spurious changes in test result diffing. I'd suggest using
the same message in all cases.
Thanks,
Pedro Alves