From: Yao Qi <yao@codesourcery.com>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb-patches ml <gdb-patches@sourceware.org>
Subject: Re: [PATCH] fix Bug 15180 Agent style dprintf does not respect conditions
Date: Tue, 23 Apr 2013 20:38:00 -0000 [thread overview]
Message-ID: <517655B9.3040805@codesourcery.com> (raw)
In-Reply-To: <CANFwon21X1C6nUjU1v6=nSGUCXEeJ2+gSPVi6U_xOaahjqFZVw@mail.gmail.com>
On 04/23/2013 03:14 PM, Hui Zhu wrote:
> + condition_true = gdb_breakpoint_here (event_child->stop_pc)
> + && gdb_condition_true_at_breakpoint (event_child->stop_pc);
> +
> /* If GDB wanted this thread to single step, we always want to
> report the SIGTRAP, and let GDB handle it. Watchpoints should
> always be reported. So should signals we can't explain. A
> @@ -2628,11 +2632,11 @@ Check if we're already there.\n",
> || event_child->stopped_by_watchpoint
> || (!step_over_finished
> && !bp_explains_trap && !trace_event)
> - || (gdb_breakpoint_here (event_child->stop_pc)
> - && gdb_condition_true_at_breakpoint (event_child->stop_pc)
> + || (condition_true
> && gdb_no_commands_at_breakpoint (event_child->stop_pc)));
>
> - run_breakpoint_commands (event_child->stop_pc);
> + if (condition_true)
> + run_breakpoint_commands (event_child->stop_pc);
Hui,
This patch works when there is only one dprintf set on a certain
address. However, supposing we set two dprintf breakpoints on the same
address, one condition is true and the other is false, commands of both
breakpoint will be executed, which is wrong. See the session below:
$ ./gdb ./testsuite/gdb.base/dprintf
(gdb) target remote :1234
(gdb) set breakpoint condition-evaluation target
// ensure that condition is evaluated in the target side.
(gdb) set dprintf-style agent
(gdb) dprintf foo , "true\n"
(gdb) condition 1 main > 1
(gdb) dprintf foo, "false\n"
(gdb) condition 2 main == 0
(gdb) info breakpoints
Num Type Disp Enb Address What
1 dprintf keep y 0x080484aa in foo at
../../../../git/gdb/testsuite/gdb.base/dprintf.c:25
stop only if main > 1 (host evals)
^^^^^^^^^^
// it should be "(target evals)", caused by a separated bug.
agent-printf "true\n"
2 dprintf keep y 0x080484aa in foo at
../../../../git/gdb/testsuite/gdb.base/dprintf.c:25
stop only if main == 0 (host evals)
agent-printf "false\n"
(gdb) c
Continuing.
[Inferior 1 (process 4135) exited with code 0152]
In the other console, we can see the output:
kickoff 1234
also to stderr 1234
false
true
false
false
true
false
false
true
false
Child exited with status 106
AFAICS, it is not a bug specific to dprintf, all target-side commands
are affected by this bug, because the command is not well grouped or
associated with condition in target side.
--
Yao (é½å°§)
prev parent reply other threads:[~2013-04-23 9:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-23 20:00 Hui Zhu
2013-04-23 20:38 ` Yao Qi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=517655B9.3040805@codesourcery.com \
--to=yao@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=teawater@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox