This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] PR 15075 dprintf interferes with "next"
- From: Tom Tromey <tromey at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Thu, 21 Feb 2013 09:35:37 -0700
- Subject: Re: [RFC] PR 15075 dprintf interferes with "next"
- References: <1361192891-29341-1-git-send-email-yao@codesourcery.com>
>>>>> "Yao" == Yao Qi <yao@codesourcery.com> writes:
Yao> The printf stuff is implemented as command, it is convenient to move
Yao> them to the target side. I tried to change the bpstat saying that
Yao> "don't stop", but the command can't be executed. We have to keep
Yao> bpstat saying that "stop" for dprintf. I also thought about Tom's
Yao> suggestion about Python "Breakpoint.stop" API, but "Breakpoint.stop"
Yao> acts as condition instead of command, so I don't go that way.
Pedro pointed out that 'stop' runs too early -- it makes "cond" not work
on a dprintf. (BTW if there is no test for this, there should be... )
But, why not just do the work just after the condition is evaluated?
For example, it could be done with special handling in
bpstat_check_breakpoint_conditions, or by introducing a new
check_condition breakpoint_ops method, with the dprintf method calling
the super method before proceeding to "printf" and then returning 0.
I tend to think that the "commands" approach is just not a good one.
Tom