satyajanga wrote: > Pretty good start. There can be more than one breakpoint at a location and we > need to be sure we test these cases. Like we can have an exception breakpoint > (which might be at `cxa_throw`) and we can have a function breakpoint for > this as well. We need to make sure we document how we are doing to display > this. If we must pick one, then lets be clear about: > > * exception breakpoints take precedence > * then function breakpoints > * then source file and line breakpoints > > If we have a free form text we can attach to the stop notification it might > be nice to see "function breakpoint & exception breakpoint", but if we have > to pick just one, then we need to be clear about what we are going to do.
Agree that there can be more than one breakpoint at a location. but 'reason' field in StoppedEvent only takes one string from fixed set of strings. > reason: 'step' | 'breakpoint' | 'exception' | 'pause' | 'entry' | 'goto' | > 'function breakpoint' | 'data breakpoint' | 'instruction breakpoint' | string; https://microsoft.github.io/debug-adapter-protocol/specification#Events_Stopped So the existing logic for instruction_breakpoint only sets the reason as 'instruction breakpoint' if all the breakpoints are instruction_breakpoints. Current behavior 1. if all the breakpoints are exception breakpoints set reason = 'exception' 2. if all the breakpoints are function breakpoints set reason = 'function breakpoint' 3. if all the breakpoints are instruction breakpoints set reason = 'instruction breakpoint' 4. if there are combination of one more breakpoints , then the reason will be 'breakpoint' I think this is a reasonable behavior, I will document this in the code. @clayborg let me know what you think? https://github.com/llvm/llvm-project/pull/130841 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
