> On Oct 8, 2015, at 1:03 AM, Keno Fischer via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > Hi folks, > > I'm using the C++ API to create a breakpoint with callback. In the callback I > do some stuff and then always return false, to have the process continue. > This works great, except when a breakpoint hit is coincident with another > breakpoint (in my case I ran into this with both the jit breakpoint and the > gdb_image_notifier breakpoint). I turned on logging and saw: > > Process::PerfomAction returning from action with m_should_stop: 1 > Process::PerfomAction returning from action with m_should_stop: 0 > > so I added the breakpoint id to the log to figure out which breakpoint was > causing the stop: > > Process::PerfomAction returning from action at id -1 with m_should_stop: 1 > Process::PerfomAction returning from action at id 2 with m_should_stop: 0 > > where -1 is the JIT breakpoint. Any ideas why this might be happening? > Looking through the rest of the log, I never see the message about > Process::PerfomAction when -1 only is hit (though always when only 2 is hit). > Is the second breakpoint somehow forcing PerformAction to be called on all of > them even though it shouldn't be?
The way the breakpoint actions are designed to work, when there is more than one breakpoint at the stop address, is that ALL the actions get to run regardless of their return value, then if all the actions want to continue the process, it continues, but if any one of them wants to stop, then it will stop. That seemed the most reasonable way to do it because you can reinstate a denied request to continue by manually continuing, but you can't reinstate a denied request to stop if you are already running. It also seems best to let all the actions run if possible, since otherwise any accounting they want to do will get off. Note, you can currently override this if you want to by calling SBProcess::Continue in your callback, since that will restart the process, and then the subsequent actions won't be able to run. That means that which actions get to run and which get preempted is dependent on the order that lldb happens to run the actions, which is kind of gross. This is really an accident not a feature, and at some point I'll get around to making "SBProcess::Continue" in the context of a breakpoint command only request the continue, so then it would all be deterministic. If there's sufficient demand for a breakpoint action to force the continue, we could add machinery to do that, but I don't think that should be the default behavior. I haven't looked at the code that handles hitting the JIT breakpoint, but it is probably having the action return should_stop = 1 because it is assuming some code that is going to get triggered after the breakpoint decides to stop will restart if appropriate. But I can't guess off the top of my head why having another breakpoint that didn't want to stop would defeat this. Jim > > Keno > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
