<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 31, 2017 at 10:43 AM Jim Ingham <<a href="mailto:jingham@apple.com">jingham@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Oct 31, 2017, at 9:05 AM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
><br>
> This is a case where I think a new API *would* be warranted.  But it would not be an API specifically for the -m option.  It would instead be an API that introduces an `SBBreakpointOptions` class, and then add a method called `BreakpointCreateWithOptions(options)`.<br>
<br>
That's almost right.  I want to keep the options that determine WHERE locations get set separate from the options that determine what happens WHEN a breakpoint gets hit.  The "reaction" options can be shared with the SBBreakpointName class and with Stop Hooks, and with a little fiddling should also be sharable with Watchpoints.  The only difference between watchpoints & breakpoints is the meaning of the ID they get passed however.  If you really wanted to share the options broadly, we'd probably have to also tell you what kind of stop this was for.  Anyway, for these reasons it is valuable to keep this part of the breakpoint specification separate.  But at the lldb_private layer these are already all gathered into their own class so promoting them would be straightforward.<br>
<br>
The setting options aren't factored into their own class at the lldb_private layer.  They get used directly to make the search filters & kernels that actually implement the breakpoint, so that class wasn't really needed.  But it wouldn't be that hard to make an intermediary that gathers up these options for convenience.  Then you'd have:<br>
<br>
SBBreakpoint BreakpointCreateWithOptions(SBBreakpointSettingOptions &setting_options, SBStoppointOptions &reaction_options);<br></blockquote><div><br></div><div>That makes sense, I can get behind something like this.  I might quibble over the names a little bit in the interest of brevity (e.g. something like SBBreakpointLocation and SBBreakpointAction), but that's minor. </div></div></div>