[PATCH] make "set debug target" take effect immediately

[Pedro Alves]

On 07/29/2014 08:18 AM, Yao Qi wrote:
> On 07/29/2014 03:04 AM, Tom Tromey wrote:
>> diff --git a/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp b/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
>> index a196f68..dd793bd 100644
>> --- a/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
>> +++ b/gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp
>> @@ -76,7 +76,7 @@ if { $hardware_step } {
>>      return
>>  }
>>  
>> -gdb_test_no_output "set debug target 0"
>> +gdb_test "set debug target 0" "->to_log_command.*\\)"
>>  
>>  set line_re "\[^\r\n\]*"
> 
> Tom,
> Beside this change, we still need to update the pattern to match the
> output of "set debug target 1".  We match "target_resume " nowadays,
> but it doesn't exist in the output at all, because of the recent target
> delegation changes.  In sss-bp-on-user-bp-2.exp, we have
> 
> gdb_test_no_output "set debug target 1"
> set hardware_step 0
> set test "probe target hardware step"
> gdb_test_multiple "si" $test {
>     -re "target_resume \\(\[^\r\n\]+, step, .*$gdb_prompt $" {
>          ^^^^^^^^^^^^^
> 	set hardware_step 1
> 	pass $test
>     }
>     -re "$gdb_prompt $" {
> 	pass $test
>     }
> }
> 
> We need to replace "target_resume" with "to_resume" in the pattern,
> otherwise, hardware_step is always zero, which is wrong.  

Definitely.  Thanks for noticing that.

> Even
> hardware_step is zero on x86, the test only fails once in about 10 runs.
> That may be the reason we didn't find the mistake before.

Yep.  For reference, git 829155c9 says:

    "The problem is that we had just resumed the target and the native
    GNU/Linux target can't read memory off of a running thread.  Most of
    the time, we get "lucky", because we manage to read memory before the
    kernel actually schedules the target to run."

-- 
Thanks,
Pedro Alves