make "set debug target" take effect immediately
Commit Message
Right now, "set debug target" acts a bit strangely.
Most target APIs only notice that it has changed when the target stack
is changed in some way. This is because many methods implement the
setting using the special debug target. However, a few spots do
change their behavior immediately -- any place explicitly checking
"targetdebug".
Some of this peculiar behavior is documented. However, I think that
it just isn't very useful for it to work this way. So, This patch
changes "set debug target" to take effect immediately in all cases.
This is done by simply calling update_current_target when the setting
is changed.
This required one small change in the test suite. Here a test was
expecting the current behavior.
Built and regtested on x86-64 Fedora 20.
2014-07-28 Tom Tromey <tromey@redhat.com>
* target.c (set_targetdebug): New function.
(initialize_targets): Pass set_targetdebug when creating "set
debug target".
2014-07-28 Tom Tromey <tromey@redhat.com>
* gdb.texinfo (Debugging Output): Update for change to "set debug
target".
2014-07-28 Tom Tromey <tromey@redhat.com>
* gdb.base/sss-bp-on-user-bp-2.exp: Expect output from "set debug
target 0".
---
gdb/ChangeLog | 6 ++++++
gdb/doc/ChangeLog | 5 +++++
gdb/doc/gdb.texinfo | 3 +--
gdb/target.c | 11 ++++++++++-
gdb/testsuite/ChangeLog | 5 +++++
gdb/testsuite/gdb.base/sss-bp-on-user-bp-2.exp | 2 +-
6 files changed, 28 insertions(+), 4 deletions(-)
Comments
> From: Tom Tromey <tromey@redhat.com>
> Cc: Tom Tromey <tromey@redhat.com>
> Date: Mon, 28 Jul 2014 13:04:27 -0600
>
> 2014-07-28 Tom Tromey <tromey@redhat.com>
>
> * gdb.texinfo (Debugging Output): Update for change to "set debug
> target".
This part is approved.
> static void
> show_targetdebug (struct ui_file *file, int from_tty,
> struct cmd_list_element *c, const char *value)
> @@ -3556,7 +3565,7 @@ Show target debugging."), _("\
> When non-zero, target debugging is enabled. Higher numbers are more\n\
> verbose. Changes do not take effect until the next \"run\" or \"target\"\n\
> command."),
The 2nd sentence of the doc string says something that you deleted
from the manual. Shouldn't it be deleted from here as well?
Thanks.
> Date: Mon, 28 Jul 2014 22:18:47 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org, tromey@redhat.com
>
> > When non-zero, target debugging is enabled. Higher numbers are more\n\
> > verbose. Changes do not take effect until the next \"run\" or \"target\"\n\
> > command."),
>
> The 2nd sentence of the doc string says something that you deleted
> from the manual.
Sorry, I meant the 3rd sentence, of course.
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. 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.
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."
On 07/28/2014 08:04 PM, Tom Tromey wrote:
> Right now, "set debug target" acts a bit strangely.
>
> Most target APIs only notice that it has changed when the target stack
> is changed in some way. This is because many methods implement the
> setting using the special debug target. However, a few spots do
> change their behavior immediately -- any place explicitly checking
> "targetdebug".
>
> Some of this peculiar behavior is documented. However, I think that
> it just isn't very useful for it to work this way. So, This patch
> changes "set debug target" to take effect immediately in all cases.
Definitely. Thanks!
> This is done by simply calling update_current_target when the setting
> is changed.
Pedro Alves
@@ -22996,8 +22996,7 @@ Show the current state of symbol table creation debugging.
Turns on or off display of @value{GDBN} target debugging info. This info
includes what is going on at the target level of GDB, as it happens. The
default is 0. Set it to 1 to track events, and to 2 to also track the
-value of large memory transfers. Changes to this flag do not take effect
-until the next time you connect to a target or use the @code{run} command.
+value of large memory transfers.
@item show debug target
Displays the current state of displaying @value{GDBN} target debugging
info.
@@ -120,6 +120,8 @@ static void init_dummy_target (void);
static void debug_to_open (char *, int);
+static void update_current_target (void);
+
/* Pointer to array of target architecture structures; the size of the
array; the current index into the array; the allocated size of the
array. */
@@ -175,6 +177,13 @@ int may_stop = 1;
/* Non-zero if we want to see trace of target level stuff. */
static unsigned int targetdebug = 0;
+
+static void
+set_targetdebug (char *args, int from_tty, struct cmd_list_element *c)
+{
+ update_current_target ();
+}
+
static void
show_targetdebug (struct ui_file *file, int from_tty,
struct cmd_list_element *c, const char *value)
@@ -3556,7 +3565,7 @@ Show target debugging."), _("\
When non-zero, target debugging is enabled. Higher numbers are more\n\
verbose. Changes do not take effect until the next \"run\" or \"target\"\n\
command."),
- NULL,
+ set_targetdebug,
show_targetdebug,
&setdebuglist, &showdebuglist);
@@ -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\]*"