This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]