[PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Lancelot SIX]

When running gdb.threads/process-dies-while-detaching.exp on
riscv64-linux-gnu, I ran on a test which is not suited to be executed on
platforms that do not support hardware watchpoints.

The first clue is this first error:

    (gdb) watch globalvar
    Watchpoint 2: globalvar
    (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: watch globalvar

With the associated test being:

    gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"

This regular expression only accepts hardware watchpoints which would
have printed something like "Hardware watchpoint  2: globalvar".  This
could easily be fixed, but there is more to come.  The next section of
the test continues until the _exit function.  Looking at the log, we can
see this times out.

    (gdb) continue
    Continuing.
    [New Thread 0x3ff7ea5150 (LWP 2529916)]
    [New Thread 0x3ff76a4150 (LWP 2529917)]
    [New Thread 0x3ff6ea3150 (LWP 2529918)]
    FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: continue to breakpoint: _exit (timeout)
    detach
    [New Thread 0x3ff66a2150 (LWP 2529919)]
    [New Thread 0x3ff5ea1150 (LWP 2529920)]
    [New Thread 0x3ff56a0150 (LWP 2529921)]
    [New Thread 0x3ff4e9f150 (LWP 2529922)]
    ...

Out of curiosity I launched manually the test, and this 'continue' using
software watchpoint is orders of magnitude longer to run than the entire
GDB testsuite (to be honest, I did not even let it finish).

With those two elements, I looks like that even if this test could be
executed on platform without hardware watchpoint, it is not advisable to
do so.

In this commit I propose to disable the parts of the tests that
are problematic when hardware support is not available.

Tested on risc64-linux-gnu
---
 gdb/testsuite/gdb.threads/process-dies-while-detaching.exp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
index ac1aad26ec5..0130db9668d 100644
--- a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
+++ b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
@@ -236,6 +236,12 @@ proc test_detach {multi_process cmd} {
 # Same as test_detach, except set a watchpoint before detaching.
 
 proc test_detach_watch {multi_process cmd} {
+    if {[skip_hw_watchpoint_tests]} {
+	# Using software watchpoint is way to slow to be included in the test.
+	# Trying to continue in this proc would result in a lot of FAILS due to
+	# timeouts.
+	return
+    }
     with_test_prefix "watchpoint" {
 	global binfile decimal
 
-- 
2.30.2

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Tom de Vries]

[ oops, add missing gdb-patches@ ]

On 9/22/21 3:13 PM, Tom de Vries wrote:
> On 9/21/21 10:24 PM, Lancelot SIX via Gdb-patches wrote:
>> When running gdb.threads/process-dies-while-detaching.exp on
>> riscv64-linux-gnu, I ran on a test which is not suited to be executed on
>> platforms that do not support hardware watchpoints.
>>
>> The first clue is this first error:
>>
>>     (gdb) watch globalvar
>>     Watchpoint 2: globalvar
>>     (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: watch globalvar
>>
>> With the associated test being:
>>
>>     gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
>>
>> This regular expression only accepts hardware watchpoints which would
>> have printed something like "Hardware watchpoint  2: globalvar".  This
>> could easily be fixed, but there is more to come.  The next section of
>> the test continues until the _exit function.  Looking at the log, we can
>> see this times out.
>>
>>     (gdb) continue
>>     Continuing.
>>     [New Thread 0x3ff7ea5150 (LWP 2529916)]
>>     [New Thread 0x3ff76a4150 (LWP 2529917)]
>>     [New Thread 0x3ff6ea3150 (LWP 2529918)]
>>     FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: continue to breakpoint: _exit (timeout)
>>     detach
>>     [New Thread 0x3ff66a2150 (LWP 2529919)]
>>     [New Thread 0x3ff5ea1150 (LWP 2529920)]
>>     [New Thread 0x3ff56a0150 (LWP 2529921)]
>>     [New Thread 0x3ff4e9f150 (LWP 2529922)]
>>     ...
>>
>> Out of curiosity I launched manually the test, and this 'continue' using
>> software watchpoint is orders of magnitude longer to run than the entire
>> GDB testsuite (to be honest, I did not even let it finish).
>>
>> With those two elements, I looks like that even if this test could be
>> executed on platform without hardware watchpoint, it is not advisable to
>> do so.
>>
>> In this commit I propose to disable the parts of the tests that
>> are problematic when hardware support is not available.
>>
> Hi,
> 
> thanks for looking into this.
> 
> You made me curious, and I managed to reproduce on x86_64, by forcing sw
> watchpoints.
> 
> I'd like to propose a different fix.  Can you check whether this solves
> your problem?
> 
> Thanks,
> - Tom
> 
> 
> 0001-gdb-testsuite-Test-sw-watchpoint-in-gdb.threads-process-dies-while-detaching.exp.patch
> 
> [gdb/testsuite] Test sw watchpoint in gdb.threads/process-dies-while-detaching.exp
> 
> The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s
> when using hw watchpoints, but when forcing sw watchpoints (using the patch
> mentioned in PR28375#c0), the test-case takes instead 3m14s.
> 
> Also, it show a FAIL:
> ...
> (gdb) continue^M
> Continuing.^M
> Cannot find user-level thread for LWP 10324: generic error^M
> (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process:
> continue: watchpoint: continue
> ...
> for which PR28375 was filed.
> 
> Modify the test-case to:
> - add the hw/sw axis to the watchpoint testing, to ensure that we
>   observe the sw watchpoint behaviour also on can-use-hw-watchpoints
>   architectures.
> - skip the hw breakpoint testing if not supported
> - set the sw watchpoint later to avoid making the test
>   too slow (which is particularly problematic for slower targets, as
>   reported by Lancelot Six for riscv64-linux-gnu).  This still triggers
>   the same PR, but now takes just 24s.
> 
> This patch adds a KFAIL for PR28375.
> 
> Tested on x86_64-linux.
> 
> ---
>  .../gdb.threads/process-dies-while-detaching.exp   | 41 ++++++++++++++++------
>  1 file changed, 30 insertions(+), 11 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
> index ac1aad26ec5..ab5a82bef71 100644
> --- a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
> +++ b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
> @@ -235,8 +235,12 @@ proc test_detach {multi_process cmd} {
>  
>  # Same as test_detach, except set a watchpoint before detaching.
>  
> -proc test_detach_watch {multi_process cmd} {
> -    with_test_prefix "watchpoint" {
> +proc test_detach_watch {wp multi_process cmd} {
> +    if { $wp == "hw" && [skip_hw_watchpoint_tests] } {
> +	unsupported "hw watchpoint"
> +	return
> +    }
> +    with_test_prefix "watchpoint:$wp" {
>  	global binfile decimal
>  
>  	clean_restart ${binfile}
> @@ -254,15 +258,28 @@ proc test_detach_watch {multi_process cmd} {
>  	    gdb_continue_to_breakpoint "child_function" ".*"
>  	}
>  
> -	# Set a watchpoint in the child.
> -	gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
> +	if { $wp == "hw" } {
> +	    # Set a watchpoint in the child.
> +	    gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
>  
> -	# Continue to the _exit breakpoint.  This arms the watchpoint
> -	# registers in all threads.  Detaching will thus need to clear
> -	# them out, and handle the case of the thread disappearing
> -	# while doing that (on targets that need to detach from each
> -	# thread individually).
> -	continue_to_exit_bp
> +	    # Continue to the _exit breakpoint.  This arms the watchpoint
> +	    # registers in all threads.  Detaching will thus need to clear
> +	    # them out, and handle the case of the thread disappearing
> +	    # while doing that (on targets that need to detach from each
> +	    # thread individually).
> +	    continue_to_exit_bp
> +	} else {
> +	    # Force software watchpoints.
> +	    gdb_test_no_output "set can-use-hw-watchpoints 0"
> +
> +	    # As above, but flip order, other wise things take too long.
> +	    continue_to_exit_bp
> +	    gdb_test "watch globalvar" "Watchpoint $decimal: globalvar"
> +
> +	    if { $multi_process == 0 && $cmd == "continue" } {
> +		setup_kfail "gdb/28375" "*-*-*"
> +	    }
> +	}
>  
>  	do_detach $multi_process $cmd "normal"
>      }
> @@ -332,7 +349,9 @@ proc do_test {multi_process cmd} {
>      }
>  
>      test_detach $multi_process $cmd
> -    test_detach_watch $multi_process $cmd
> +    foreach wp {"sw" "hw"} {
> +	test_detach_watch $wp $multi_process $cmd
> +    }
>      test_detach_killed_outside $multi_process $cmd
>  }
>  
> 

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Lancelot SIX]

Hi,

I had a look at your patch, it is for sure a better approach than mine.

At some point you change the order between the 'continue_to_exit_bp' and
'watch' commands when forcing software watchpoint.  Any reason not to
use the same order for both cases?

If I run with it I have the expected summary:

	                === gdb Summary ===
	
	# of expected passes            69
	# of known failures             1
	# of unsupported tests          4

However, looking at the log here is what I got:

	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue to breakpoint: _exit
	watch globalvar
	Watchpoint 3: globalvar
	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
	continue
	Continuing.
	[Thread 0x3fea68a150 (LWP 2358916) exited]
	[...]
	[Thread 0x3ff7ea5150 (LWP 2358889) exited]
	KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (timeout) (PRMS: gdb/28375)

This does not look like what you reported in PR28375.  I guess the
setup_kfail should be adjusted to account for the two way this test can
fail (I am not sure if they both come down to the same problem or not).

Here is what I have observed so far on my platform.  At the end of the
test, all the threads have exited (I have all the '[Threas hex (LWP
digit) exited]' I am expecting.  However the test hangs there.
Attaching to the running GDB, I can see that it is waiting in  'pool'
under 'gdb_wait_for_event'.  I still have to investigate why this is
happening.

I also believe that this is what I had with my initial very long running
execution.  Even if things are really slow with software watchpoint,
waiting for an event that does not come is a bigger problem.

I’ll need more time to figure out what is going on, and probably some
more to see if I can fix it.

Best,
Lancelot.

On Wed, Sep 22, 2021 at 03:15:44PM +0200, Tom de Vries wrote:
> [ oops, add missing gdb-patches@ ]
> 
> On 9/22/21 3:13 PM, Tom de Vries wrote:
> > On 9/21/21 10:24 PM, Lancelot SIX via Gdb-patches wrote:
> >> When running gdb.threads/process-dies-while-detaching.exp on
> >> riscv64-linux-gnu, I ran on a test which is not suited to be executed on
> >> platforms that do not support hardware watchpoints.
> >>
> >> The first clue is this first error:
> >>
> >>     (gdb) watch globalvar
> >>     Watchpoint 2: globalvar
> >>     (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: watch globalvar
> >>
> >> With the associated test being:
> >>
> >>     gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
> >>
> >> This regular expression only accepts hardware watchpoints which would
> >> have printed something like "Hardware watchpoint  2: globalvar".  This
> >> could easily be fixed, but there is more to come.  The next section of
> >> the test continues until the _exit function.  Looking at the log, we can
> >> see this times out.
> >>
> >>     (gdb) continue
> >>     Continuing.
> >>     [New Thread 0x3ff7ea5150 (LWP 2529916)]
> >>     [New Thread 0x3ff76a4150 (LWP 2529917)]
> >>     [New Thread 0x3ff6ea3150 (LWP 2529918)]
> >>     FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: continue to breakpoint: _exit (timeout)
> >>     detach
> >>     [New Thread 0x3ff66a2150 (LWP 2529919)]
> >>     [New Thread 0x3ff5ea1150 (LWP 2529920)]
> >>     [New Thread 0x3ff56a0150 (LWP 2529921)]
> >>     [New Thread 0x3ff4e9f150 (LWP 2529922)]
> >>     ...
> >>
> >> Out of curiosity I launched manually the test, and this 'continue' using
> >> software watchpoint is orders of magnitude longer to run than the entire
> >> GDB testsuite (to be honest, I did not even let it finish).
> >>
> >> With those two elements, I looks like that even if this test could be
> >> executed on platform without hardware watchpoint, it is not advisable to
> >> do so.
> >>
> >> In this commit I propose to disable the parts of the tests that
> >> are problematic when hardware support is not available.
> >>
> > Hi,
> > 
> > thanks for looking into this.
> > 
> > You made me curious, and I managed to reproduce on x86_64, by forcing sw
> > watchpoints.
> > 
> > I'd like to propose a different fix.  Can you check whether this solves
> > your problem?
> > 
> > Thanks,
> > - Tom
> > 
> > 
> > 0001-gdb-testsuite-Test-sw-watchpoint-in-gdb.threads-process-dies-while-detaching.exp.patch
> > 
> > [gdb/testsuite] Test sw watchpoint in gdb.threads/process-dies-while-detaching.exp
> > 
> > The test-case gdb.threads/process-dies-while-detaching.exp takes about 20s
> > when using hw watchpoints, but when forcing sw watchpoints (using the patch
> > mentioned in PR28375#c0), the test-case takes instead 3m14s.
> > 
> > Also, it show a FAIL:
> > ...
> > (gdb) continue^M
> > Continuing.^M
> > Cannot find user-level thread for LWP 10324: generic error^M
> > (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process:
> > continue: watchpoint: continue
> > ...
> > for which PR28375 was filed.
> > 
> > Modify the test-case to:
> > - add the hw/sw axis to the watchpoint testing, to ensure that we
> >   observe the sw watchpoint behaviour also on can-use-hw-watchpoints
> >   architectures.
> > - skip the hw breakpoint testing if not supported
> > - set the sw watchpoint later to avoid making the test
> >   too slow (which is particularly problematic for slower targets, as
> >   reported by Lancelot Six for riscv64-linux-gnu).  This still triggers
> >   the same PR, but now takes just 24s.
> > 
> > This patch adds a KFAIL for PR28375.
> > 
> > Tested on x86_64-linux.
> > 
> > ---
> >  .../gdb.threads/process-dies-while-detaching.exp   | 41 ++++++++++++++++------
> >  1 file changed, 30 insertions(+), 11 deletions(-)
> > 
> > diff --git a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
> > index ac1aad26ec5..ab5a82bef71 100644
> > --- a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
> > +++ b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
> > @@ -235,8 +235,12 @@ proc test_detach {multi_process cmd} {
> >  
> >  # Same as test_detach, except set a watchpoint before detaching.
> >  
> > -proc test_detach_watch {multi_process cmd} {
> > -    with_test_prefix "watchpoint" {
> > +proc test_detach_watch {wp multi_process cmd} {
> > +    if { $wp == "hw" && [skip_hw_watchpoint_tests] } {
> > +	unsupported "hw watchpoint"
> > +	return
> > +    }
> > +    with_test_prefix "watchpoint:$wp" {
> >  	global binfile decimal
> >  
> >  	clean_restart ${binfile}
> > @@ -254,15 +258,28 @@ proc test_detach_watch {multi_process cmd} {
> >  	    gdb_continue_to_breakpoint "child_function" ".*"
> >  	}
> >  
> > -	# Set a watchpoint in the child.
> > -	gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
> > +	if { $wp == "hw" } {
> > +	    # Set a watchpoint in the child.
> > +	    gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
> >  
> > -	# Continue to the _exit breakpoint.  This arms the watchpoint
> > -	# registers in all threads.  Detaching will thus need to clear
> > -	# them out, and handle the case of the thread disappearing
> > -	# while doing that (on targets that need to detach from each
> > -	# thread individually).
> > -	continue_to_exit_bp
> > +	    # Continue to the _exit breakpoint.  This arms the watchpoint
> > +	    # registers in all threads.  Detaching will thus need to clear
> > +	    # them out, and handle the case of the thread disappearing
> > +	    # while doing that (on targets that need to detach from each
> > +	    # thread individually).
> > +	    continue_to_exit_bp
> > +	} else {
> > +	    # Force software watchpoints.
> > +	    gdb_test_no_output "set can-use-hw-watchpoints 0"
> > +
> > +	    # As above, but flip order, other wise things take too long.
> > +	    continue_to_exit_bp
> > +	    gdb_test "watch globalvar" "Watchpoint $decimal: globalvar"
> > +
> > +	    if { $multi_process == 0 && $cmd == "continue" } {
> > +		setup_kfail "gdb/28375" "*-*-*"
> > +	    }
> > +	}
> >  
> >  	do_detach $multi_process $cmd "normal"
> >      }
> > @@ -332,7 +349,9 @@ proc do_test {multi_process cmd} {
> >      }
> >  
> >      test_detach $multi_process $cmd
> > -    test_detach_watch $multi_process $cmd
> > +    foreach wp {"sw" "hw"} {
> > +	test_detach_watch $wp $multi_process $cmd
> > +    }
> >      test_detach_killed_outside $multi_process $cmd
> >  }
> >  
> > 

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Tom de Vries]

On 9/22/21 11:40 PM, Lancelot SIX wrote:
> Hi,
> 
> I had a look at your patch, it is for sure a better approach than mine.
> 
> At some point you change the order between the 'continue_to_exit_bp' and
> 'watch' commands when forcing software watchpoint.  Any reason not to
> use the same order for both cases?
> 

Yes, because sw watchpoints are slow.

> 	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
> 	continue
> 	Continuing.
> 	[Thread 0x3fea68a150 (LWP 2358916) exited]
> 	[...]
> 	[Thread 0x3ff7ea5150 (LWP 2358889) exited]
> 	KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (timeout) (PRMS: gdb/28375)
> 
> This does not look like what you reported in PR28375.  I guess the
> setup_kfail should be adjusted to account for the two way this test can
> fail (I am not sure if they both come down to the same problem or not).
> 

Is there a gdb prompt inbetween the PASS and KFAIL?

Thanks,
- Tom

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Lancelot SIX]

On Sun, Sep 26, 2021 at 11:54:02AM +0200, Tom de Vries wrote:
> On 9/22/21 11:40 PM, Lancelot SIX wrote:
> > Hi,
> > 
> > I had a look at your patch, it is for sure a better approach than mine.
> > 
> > At some point you change the order between the 'continue_to_exit_bp' and
> > 'watch' commands when forcing software watchpoint.  Any reason not to
> > use the same order for both cases?
> > 
> 
> Yes, because sw watchpoints are slow.

I mean I totally understand why it makes sense to move the 'watch'
command after continue_to_exit_bp when using software watchpoints. The
question was more is there a reason not to do the same for hardware
watchpoints?  I do not expect any 'gain' from doing the same with
hardware assisted watchpoint except having something similar in both
cases.

> 
> > 	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
> > 	continue
> > 	Continuing.
> > 	[Thread 0x3fea68a150 (LWP 2358916) exited]
> > 	[...]
> > 	[Thread 0x3ff7ea5150 (LWP 2358889) exited]
> > 	KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (timeout) (PRMS: gdb/28375)
> > 
> > This does not look like what you reported in PR28375.  I guess the
> > setup_kfail should be adjusted to account for the two way this test can
> > fail (I am not sure if they both come down to the same problem or not).
> > 
> 
> Is there a gdb prompt inbetween the PASS and KFAIL?

No. In the snippet I provided above, the '[...]' skips a bunch of
'[Thread 0xXXXXXXXXXX (LWP XXXXXXX) exited] ', and nothing else.

Looking into this I fixed an omission in the RISC-V prologue analyzer for which
I plan in submitting a patch later when I have found time to write a testcase
for it.  With this being fixed, the log for
gdb.threads/process-dies-while-detaching.exp becomes:

	watch globalvar
	Watchpoint 3: globalvar
	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
	continue
	Continuing.
	Cannot access memory at address 0x3ff7f2e324
	(gdb) KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (PRMS: gdb/28375)
	UNSUPPORTED: gdb.threads/process-dies-while-detaching.exp: single-process: continue: hw watchpoint

I’ll continue to work on this when possible.

Best,
Lancelot.
> 
> Thanks,
> - Tom

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Tom de Vries]

On 9/26/21 7:11 PM, Lancelot SIX wrote:
> On Sun, Sep 26, 2021 at 11:54:02AM +0200, Tom de Vries wrote:
>> On 9/22/21 11:40 PM, Lancelot SIX wrote:
>>> Hi,
>>>
>>> I had a look at your patch, it is for sure a better approach than mine.
>>>
>>> At some point you change the order between the 'continue_to_exit_bp' and
>>> 'watch' commands when forcing software watchpoint.  Any reason not to
>>> use the same order for both cases?
>>>
>>
>> Yes, because sw watchpoints are slow.
> 
> I mean I totally understand why it makes sense to move the 'watch'
> command after continue_to_exit_bp when using software watchpoints. The
> question was more is there a reason not to do the same for hardware
> watchpoints? 

Yes, the fact that the existing test-case comments in detail about that
order for hardware watchpoints.  I don't want to break the existing
test-case.

> I do not expect any 'gain' from doing the same with
> hardware assisted watchpoint except having something similar in both
> cases.
> 
>>
>>> 	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
>>> 	continue
>>> 	Continuing.
>>> 	[Thread 0x3fea68a150 (LWP 2358916) exited]
>>> 	[...]
>>> 	[Thread 0x3ff7ea5150 (LWP 2358889) exited]
>>> 	KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (timeout) (PRMS: gdb/28375)
>>>
>>> This does not look like what you reported in PR28375.  I guess the
>>> setup_kfail should be adjusted to account for the two way this test can
>>> fail (I am not sure if they both come down to the same problem or not).
>>>
>>
>> Is there a gdb prompt inbetween the PASS and KFAIL?
> 
> No. In the snippet I provided above, the '[...]' skips a bunch of
> '[Thread 0xXXXXXXXXXX (LWP XXXXXXX) exited] ', and nothing else.
> 

Ack, thanks for clarifying this.

> Looking into this I fixed an omission in the RISC-V prologue analyzer for which
> I plan in submitting a patch later when I have found time to write a testcase
> for it.  With this being fixed, the log for
> gdb.threads/process-dies-while-detaching.exp becomes:
> 
> 	watch globalvar
> 	Watchpoint 3: globalvar
> 	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
> 	continue
> 	Continuing.
> 	Cannot access memory at address 0x3ff7f2e324
> 	(gdb) KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (PRMS: gdb/28375)
> 	UNSUPPORTED: gdb.threads/process-dies-while-detaching.exp: single-process: continue: hw watchpoint
> 

Ok, then perhaps the KFAIL doesn't need an update.

> I’ll continue to work on this when possible.
> 

Great.  I'll commit the version I posted, unless there other objections.

Thanks,
- Tom

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Tom de Vries]

On 9/27/21 12:43 AM, Tom de Vries wrote:
> On 9/26/21 7:11 PM, Lancelot SIX wrote:
>> On Sun, Sep 26, 2021 at 11:54:02AM +0200, Tom de Vries wrote:
>>> On 9/22/21 11:40 PM, Lancelot SIX wrote:
>> Looking into this I fixed an omission in the RISC-V prologue analyzer for which
>> I plan in submitting a patch later when I have found time to write a testcase
>> for it.  With this being fixed, the log for
>> gdb.threads/process-dies-while-detaching.exp becomes:
>>
>> 	watch globalvar
>> 	Watchpoint 3: globalvar
>> 	(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: watch globalvar
>> 	continue
>> 	Continuing.
>> 	Cannot access memory at address 0x3ff7f2e324
>> 	(gdb) KFAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint:sw: continue (PRMS: gdb/28375)
>> 	UNSUPPORTED: gdb.threads/process-dies-while-detaching.exp: single-process: continue: hw watchpoint
>>
> 
> Ok, then perhaps the KFAIL doesn't need an update.
> 
>> I’ll continue to work on this when possible.
>>
> 
> Great.  I'll commit the version I posted, unless there other objections.
> 

I committed, FTR without the bit in the commit log:
...
(which is particularly problematic for slower targets, as
reported by Lancelot Six for riscv64-linux-gnu)
...
given that as I understand it, you're no longer running into the timeout
with the prologue analyzer fix.

Thanks,
- Tom

Re: [PATCH] gdb.threads/process-dies-while-detaching: disable with software watchpoint

[Lancelot SIX]

> 
> I committed, FTR without the bit in the commit log:
> ...
> (which is particularly problematic for slower targets, as
> reported by Lancelot Six for riscv64-linux-gnu)
> ...

Thanks for doing this!

> given that as I understand it, you're no longer running into the timeout
> with the prologue analyzer fix.

Correct.  I just posted a patch for that.  I still have an error (i.e.
I fail at the KFAIL as expected), but it is not a timeout anymore.

> 
> Thanks,
> - Tom

Best,
Lancelot.