This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] make "set debug target" take effect immediately
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>, Tom Tromey <tromey at redhat dot com>, gdb-patches at sourceware dot org
- Date: Tue, 29 Jul 2014 11:07:20 +0100
- Subject: Re: [PATCH] make "set debug target" take effect immediately
- Authentication-results: sourceware.org; auth=none
- References: <1406574267-5212-1-git-send-email-tromey at redhat dot com> <53D74AE0 dot 3050404 at codesourcery dot com>
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