Re: [PATCH v2] dynamic printf

[Stan Shebs <stanshebs at earthlink dot net>]

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 
funky.

Stan