[Lldb-commits] [PATCH] D52065: WWW docs for scripted breakpoint resolvers

[Jim Ingham via Phabricator via lldb-commits]

jingham marked 3 inline comments as done.
jingham added a comment.

I used your suggestion and fixed the few other bits.



================
Comment at: www/python-reference.html:325
+                <p>Another use of the Python API's in lldb is to create a custom breakpoint resolver.  This facility
+                  was added in r51967.  
+                </p>
----------------
clayborg wrote:
> Is that SVN revision high enough? Seems to be missing a digit?
Yeah, dunno how that got into my paste buffer...


================
Comment at: www/python-reference.html:334-335
+                <p>
+                  In lldb, a breakpoint is composed of three parts, the Searcher, and the Resolver, which cooperate to determine
+                  how breakpoint locations are set; and the the collection
+                  of options which determine what happens when a location triggers.  That last part includes the commands,
----------------
clayborg wrote:
> Feel free to ignore this suggestion, but maybe:
> 
> ```
> In lldb, a breakpoint is composed of three parts: the Searcher, the Resolver, and the Options. The Searcher and Resolver cooperate to determine how breakpoint locations are set and differ between each breakpoint type. Options determine what happens when a location triggers and includes the commands, conditions, ignore counts, etc. Options are common between all breakpoint types.
> ```
Nice.  I changed Options -> Stop Options because on the command you also use options to specify the resolver & filter to make it a little clearer.


================
Comment at: www/python-reference.html:348
+                  The Searcher can be provided with a SearchFilter that it will use to restrict this search.  For instance, if the
+                  SearchFilter specifies a list of good Modules, the Searcher will not recurse into Modules that aren't on the list.
+                  When you pass the <b>-s modulename</b> flag to <b>break set</b> you are creating a Module-based search filter.
----------------
clayborg wrote:
> Remove good from above?
> ```
> s/specifies a list of good Modules/specifies a list of Modules/
> ```
Sure.  We don't have black list filters at this point, only white list ones.  So "good" is redundant except if you didn't know that.  But I agree, from context this is pretty clear.


================
Comment at: www/python-reference.html:384
+                <p>
+                  At present, when adding a scripted Breakpoint type, you can only provide a custom Resolver, not a custom SearchFilter.
+                </p> 
----------------
clayborg wrote:
> ```
> At present, when adding a scripted Breakpoint type, you only need to provide a custom Resolver as the Searcher is handled automatically by LLDB using breakpoint options from the command line or SBTarget::BreakpointCreateXXX() function.
> ```
> Is it the Resolvers job to provide the search depth? Or is this a Searcher option masquerading as Resolver callback?
It is currently the Resolver's job to provide the search depth.

The Searcher's all have the ability to support any search depth, that's all in base class code.  And that's not functionality that's overridden in the actual implementation of search filters.  So the depth is a fairly inessential part of the searchers.  OTOH, the Resolver cares about what depth it gets called back at, the strategy it uses to resolve locations depends on that.  So it made sense to me for the Resolver to be the one that states the search depth, not the Searcher.

However, the Resolver doesn't create the search filter, they are independently made and assembled.  It also seemed awkward to have the assembler (the Target in this case) have to ask the Resolver "what depth do you want" and then tell that to the Search Filter.  That's not something the assembler needs to know about at all.

So it made more sense to me to have this conveyed in a communication between the Resolver & Search Filter.

When I was originally thinking about this, I didn't want to rule out the ability for the Resolver to have a state dependent control over the depth.  For instance, you might want to run over modules, but then in some particular module, ask to be fed Compile Units.  That's why I left it as a callback, not some "Resolver, configure your searcher" mechanism.  We don't use that anywhere - and I'd need to add some communication to make it possible.  But that would be pretty straightforward to do, and  given that we don't pay anything substantial to retain the possibility, I'm think the way it is done now is good.


Repository:
  rLLDB LLDB

https://reviews.llvm.org/D52065