[RFC] PR 15075 dprintf interferes with "next"

Tom Tromey tromey@redhat.com
Thu Feb 21 16:36:00 GMT 2013


>>>>> "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



More information about the Gdb-patches mailing list