[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