This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2] dynamic printf
On 5/16/12 1:52 PM, Pedro Alves wrote:
On 05/16/2012 09:46 PM, Stan Shebs wrote:
I thought this approach would break "next"ing over a dprintf location.
Indeed, thus this part of the introduction to this patch: :-)
"... Joel previously noted a problem with the "continue" in the command list, which is
that stepping/nexting over a dprintf becomes a continue instead (this is a problem for
general breakpoint command lists as well). I tinkered with bpstats a bit, but didn't
come up with a good solution.
This is normally handled by the bpstat saying "don't stop". Doesn't that work
for this? Why?
Basically if you set bs->stop to 0, command lists don't get run. It's a
little convoluted, because the code does go into bpstat_do_actions, but
nothing happens there because the copy of b->commands to bs->commands in
bpstat_stop_status only happens if bs->stop.
That's why I'm thinking of a special command / pseudo-command for the
command list; we don't necessarily want to say that we haven't stopped,
because that meaning is typically reserved for "yes we hit the trap, but
pretend it never happened". Instead, we want the effect of hitting the
breakpoint, and then go back to making progress on whichever command we
were doing. An alternative is to make bs->stop a three-state, but that
seems like a really bad idea for an area of code that is already rather