jasonmolenda wrote:
> GDB code breaks actually can have a condition list that's evaluated on the > target side: > > ``` > cond_list is an optional list of conditional expressions in bytecode form > that should be evaluated on the target’s side. These are the conditions that > should be taken into consideration when deciding if the breakpoint trigger > should be reported back to GDB. > ``` > > Which is along the same lines, but they'd need the debug server to be aware > that a software watch was set for this to be used in that situation. I'm not completely clear if this bytecode is executed in the inferior process (gdb inserts/compiles in the agent that runs the expression, inserts jumps to the agent) or if this is executed in gdbserver (it has bytecode associated with certain breakpoints, runs that, collects data or resumes execution unless a condition is matched). For a conditional breakpoint today, we hit the breakpoint trap, gdbserver/lldb-server/debugserver are invoked with that. They send a packet up to lldb saying we've stopped. lldb recognizes the breakpoint, finds a condition, does a memory/register read, checks if the condition has been met. If not, it tells the debug stub to resume the inferior, the debug stub resumes the inferior (remove breakpoint, instruction step, re-insert breakpoint, continue) If the Agent Expression is evaluated at the debug stub level, this gets lldb out of the equation but we're still halting the inferior process and context switching over to the debug stub. We're still going to be quite slow. This does allow for the debugger to (in theory) disconnect from the inferior process -- so if you were developing an app that needed to be outdoors when it was executing, being able to disconnect lldb while it is collecting data at these sample points, and downloading it later when you're back at your computer could be valuable. >From a "stopping the inferior and resuming again is slow" perspective, I'm not >sure if eliminating lldb from the equation speeds it up enough to >fundamentally change the perf tradeoffs with an approach like this. https://github.com/llvm/llvm-project/pull/151195 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
