public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
@ 2021-03-16  9:26 Markus Metzger
  2021-04-01 16:44 ` Tom Tromey
  2021-04-01 16:54 ` Luis Machado
  0 siblings, 2 replies; 7+ messages in thread
From: Markus Metzger @ 2021-03-16  9:26 UTC (permalink / raw)
  To: gdb-patches

In gdb.btrace/reconnect.exp, we test that we can disconnect and reconnect
again to a GDB session that is recording with the btrace recording format.
It does not really matter what we are recording.

The test assumed that stepping from _start will bring us into an area
without debug information.  This is not correct on all systems.

Relax the expected output to also support systems where we do have debug
information for that code.

gdb/testsuite/ChangeLog:
2021-03-08  Markus Metzger  <markus.t.metzger@intel.com>

	* gdb.btrace/reconnect.exp: Relax expected stepi output.
---
 gdb/testsuite/gdb.btrace/reconnect.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.btrace/reconnect.exp b/gdb/testsuite/gdb.btrace/reconnect.exp
index 2e61d3591f3..26578706eaf 100644
--- a/gdb/testsuite/gdb.btrace/reconnect.exp
+++ b/gdb/testsuite/gdb.btrace/reconnect.exp
@@ -51,7 +51,7 @@ gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
 # Create a record, check, reconnect
 with_test_prefix "first" {
   gdb_test_no_output "record btrace" "record btrace enable"
-  gdb_test "stepi 19" "($hex in .* from .*|$hex\t$decimal.*)"
+  gdb_test "stepi 19" ".*"
 
   gdb_test "info record" [multi_line \
     "Active record target: .*" \
-- 
2.29.2

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
  2021-03-16  9:26 [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output Markus Metzger
@ 2021-04-01 16:44 ` Tom Tromey
  2021-04-01 16:54 ` Luis Machado
  1 sibling, 0 replies; 7+ messages in thread
From: Tom Tromey @ 2021-04-01 16:44 UTC (permalink / raw)
  To: Markus Metzger via Gdb-patches

>>>>> "Markus" == Markus Metzger via Gdb-patches <gdb-patches@sourceware.org> writes:

Markus> gdb/testsuite/ChangeLog:
Markus> 2021-03-08  Markus Metzger  <markus.t.metzger@intel.com>

Markus> 	* gdb.btrace/reconnect.exp: Relax expected stepi output.

This seems fine to me.  Thank you.

Tom

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
  2021-03-16  9:26 [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output Markus Metzger
  2021-04-01 16:44 ` Tom Tromey
@ 2021-04-01 16:54 ` Luis Machado
  2021-04-12  8:22   ` Metzger, Markus T
  1 sibling, 1 reply; 7+ messages in thread
From: Luis Machado @ 2021-04-01 16:54 UTC (permalink / raw)
  To: Markus Metzger, gdb-patches

On 3/16/21 6:26 AM, Markus Metzger via Gdb-patches wrote:
> In gdb.btrace/reconnect.exp, we test that we can disconnect and reconnect
> again to a GDB session that is recording with the btrace recording format.
> It does not really matter what we are recording.
> 
> The test assumed that stepping from _start will bring us into an area
> without debug information.  This is not correct on all systems.
> 
> Relax the expected output to also support systems where we do have debug
> information for that code.
> 
> gdb/testsuite/ChangeLog:
> 2021-03-08  Markus Metzger  <markus.t.metzger@intel.com>
> 
> 	* gdb.btrace/reconnect.exp: Relax expected stepi output.
> ---
>   gdb/testsuite/gdb.btrace/reconnect.exp | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.btrace/reconnect.exp b/gdb/testsuite/gdb.btrace/reconnect.exp
> index 2e61d3591f3..26578706eaf 100644
> --- a/gdb/testsuite/gdb.btrace/reconnect.exp
> +++ b/gdb/testsuite/gdb.btrace/reconnect.exp
> @@ -51,7 +51,7 @@ gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
>   # Create a record, check, reconnect
>   with_test_prefix "first" {
>     gdb_test_no_output "record btrace" "record btrace enable"
> -  gdb_test "stepi 19" "($hex in .* from .*|$hex\t$decimal.*)"
> +  gdb_test "stepi 19" ".*"
>   
>     gdb_test "info record" [multi_line \
>       "Active record target: .*" \
> 

Investigating some racy tests under make check-read1, isn't there a 
better matching pattern that we can use here to prevent future 
non-determinism?

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
  2021-04-01 16:54 ` Luis Machado
@ 2021-04-12  8:22   ` Metzger, Markus T
  2021-04-12 11:05     ` Luis Machado
  0 siblings, 1 reply; 7+ messages in thread
From: Metzger, Markus T @ 2021-04-12  8:22 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb-patches

Hello Luis,

>> @@ -51,7 +51,7 @@ gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
>>   # Create a record, check, reconnect
>>   with_test_prefix "first" {
>>     gdb_test_no_output "record btrace" "record btrace enable"
>> -  gdb_test "stepi 19" "($hex in .* from .*|$hex\t$decimal.*)"
>> +  gdb_test "stepi 19" ".*"
>>
>>     gdb_test "info record" [multi_line \
>>       "Active record target: .*" \
>>
>
>Investigating some racy tests under make check-read1, isn't there a
>better matching pattern that we can use here to prevent future
>non-determinism?

The test now ignores all output since it doesn't really matter where we end up
after stepping.  This should be the most future-proof pattern.  Were you looking
for a less lax pattern?

I ran gdb.btrace with check-read1 on IA and didn't find any issues.

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
  2021-04-12  8:22   ` Metzger, Markus T
@ 2021-04-12 11:05     ` Luis Machado
  2021-04-12 11:09       ` Metzger, Markus T
  0 siblings, 1 reply; 7+ messages in thread
From: Luis Machado @ 2021-04-12 11:05 UTC (permalink / raw)
  To: Metzger, Markus T; +Cc: gdb-patches

Hi,

On 4/12/21 5:22 AM, Metzger, Markus T wrote:
> Hello Luis,
> 
>>> @@ -51,7 +51,7 @@ gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
>>>    # Create a record, check, reconnect
>>>    with_test_prefix "first" {
>>>      gdb_test_no_output "record btrace" "record btrace enable"
>>> -  gdb_test "stepi 19" "($hex in .* from .*|$hex\t$decimal.*)"
>>> +  gdb_test "stepi 19" ".*"
>>>
>>>      gdb_test "info record" [multi_line \
>>>        "Active record target: .*" \
>>>
>>
>> Investigating some racy tests under make check-read1, isn't there a
>> better matching pattern that we can use here to prevent future
>> non-determinism?
> 
> The test now ignores all output since it doesn't really matter where we end up
> after stepping.  This should be the most future-proof pattern.  Were you looking
> for a less lax pattern?

Yeah, I was looking for a more meaningful kind of test other than 
expecting anything.

In any case, I was worried about possible races in the test...

> 
> I ran gdb.btrace with check-read1 on IA and didn't find any issues.

... and since you verified it with read1, I guess it should be fine.

Thanks,
Luis

^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
  2021-04-12 11:05     ` Luis Machado
@ 2021-04-12 11:09       ` Metzger, Markus T
  2021-04-12 11:11         ` Luis Machado
  0 siblings, 1 reply; 7+ messages in thread
From: Metzger, Markus T @ 2021-04-12 11:09 UTC (permalink / raw)
  To: Luis Machado; +Cc: gdb-patches

Hello Luis,

>>>> @@ -51,7 +51,7 @@ gdb_target_cmd $gdbserver_protocol
>$gdbserver_gdbport
>>>>    # Create a record, check, reconnect
>>>>    with_test_prefix "first" {
>>>>      gdb_test_no_output "record btrace" "record btrace enable"
>>>> -  gdb_test "stepi 19" "($hex in .* from .*|$hex\t$decimal.*)"
>>>> +  gdb_test "stepi 19" ".*"
>>>>
>>>>      gdb_test "info record" [multi_line \
>>>>        "Active record target: .*" \
>>>>
>>>
>>> Investigating some racy tests under make check-read1, isn't there a
>>> better matching pattern that we can use here to prevent future
>>> non-determinism?
>>
>> The test now ignores all output since it doesn't really matter where we end up
>> after stepping.  This should be the most future-proof pattern.  Were you
>looking
>> for a less lax pattern?
>
>Yeah, I was looking for a more meaningful kind of test other than
>expecting anything.

The meaningful part is just outside of this hunk:

  gdb_test "info record" [multi_line \
    "Active record target: .*" \
    "Recorded 19 instructions in .+ functions \\(. gaps\\) for thread 1 \\(Thread .*\\)."
  ]

We check that we actually stepped exactly those 19 instructions.  The test doesn't
care where this brought us.

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output
  2021-04-12 11:09       ` Metzger, Markus T
@ 2021-04-12 11:11         ` Luis Machado
  0 siblings, 0 replies; 7+ messages in thread
From: Luis Machado @ 2021-04-12 11:11 UTC (permalink / raw)
  To: Metzger, Markus T; +Cc: gdb-patches

On 4/12/21 8:09 AM, Metzger, Markus T wrote:
> Hello Luis,
> 
>>>>> @@ -51,7 +51,7 @@ gdb_target_cmd $gdbserver_protocol
>> $gdbserver_gdbport
>>>>>     # Create a record, check, reconnect
>>>>>     with_test_prefix "first" {
>>>>>       gdb_test_no_output "record btrace" "record btrace enable"
>>>>> -  gdb_test "stepi 19" "($hex in .* from .*|$hex\t$decimal.*)"
>>>>> +  gdb_test "stepi 19" ".*"
>>>>>
>>>>>       gdb_test "info record" [multi_line \
>>>>>         "Active record target: .*" \
>>>>>
>>>>
>>>> Investigating some racy tests under make check-read1, isn't there a
>>>> better matching pattern that we can use here to prevent future
>>>> non-determinism?
>>>
>>> The test now ignores all output since it doesn't really matter where we end up
>>> after stepping.  This should be the most future-proof pattern.  Were you
>> looking
>>> for a less lax pattern?
>>
>> Yeah, I was looking for a more meaningful kind of test other than
>> expecting anything.
> 
> The meaningful part is just outside of this hunk:
> 
>    gdb_test "info record" [multi_line \
>      "Active record target: .*" \
>      "Recorded 19 instructions in .+ functions \\(. gaps\\) for thread 1 \\(Thread .*\\)."
>    ]
> 
> We check that we actually stepped exactly those 19 instructions.  The test doesn't
> care where this brought us.

Indeed. Thanks for making it clear.

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2021-04-12 11:11 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-16  9:26 [PATCH] gdb, testsuite, btrace: relax unneeded stepi expected output Markus Metzger
2021-04-01 16:44 ` Tom Tromey
2021-04-01 16:54 ` Luis Machado
2021-04-12  8:22   ` Metzger, Markus T
2021-04-12 11:05     ` Luis Machado
2021-04-12 11:09       ` Metzger, Markus T
2021-04-12 11:11         ` Luis Machado

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).