[Lldb-commits] [PATCH] D121631: Introduce new symbol on-demand for debug info

Tue Mar 15 20:22:40 PDT 2022

> On Mar 15, 2022, at 5:03 PM, Greg Clayton via Phabricator <reviews at reviews.llvm.org> wrote:
> 
> clayborg added a comment.
> 
> In D121631#3380824 <https://reviews.llvm.org/D121631#3380824>, @jingham wrote:
> 
>> This sort of change needs to do a lot more work to help the user understand what they can and can't see if they accept the speed for visibility tradeoff.
>> 
>> They (and we) also need to know what operations might trigger a full "hydration" of a symbol table.  It isn't useful to have all this infrastructure in place if fairly common operations trigger all the work anyway.
> 
> Symbol tables are always on and are used to help us find things that will possibly be in the debug info from a function name (look for Code symbols) and global variable (Data symbols) perspective. So a few things here:
> 
> - symbol tables are always parsed for everything and help us enable debug info if we find a match for FindFunctions and FindGlobals calls on the symbol file even if these SymbolFile calls specify to not check the symbol table. If we find a symbol that matches, we turn on debug info and repeat the call by calling into the symbol file if debug info wasn't previously enabled.
> - any Address -> symbol context where the user asks for debug info enables debug info: which usually means any PC from any stack frame, but can also mean if a user queries an address
> - line tables are always left enabled and if any match occurs we enable debug info
> 
>> It also seems to me that whenever the user tells about a shared library, we should "hydrate" it.  So for instance, if I do:
>> 
>> (lldb) break set -s someLib.dylib -f foo.c -l 12
>> 
>> they you should first hydrate someLib.dylib and then set the breakpoint.
> 
> that already works. Line tables are relatively cheap and they are always enabled through SymbolFileOnDemand and if. "foo.c:12" kicks up any matches, regardless of wether the shared library was specified, will enable debug info for any libraries that match.
> 
>> In general, there should be a strategy discussion up-front before just making this change, with use cases of what won't work (not just some disabled tests) and how ordinary users might figure out something didn't work because of the on-demand loading.  There needs to also be a way for lldb to inform users what to expect or the experience will just end up being frustrating.
> 
> Jim: I met with you to discuss all of these strategies a month ago and I left with the impression the ideas I told you about could work pretty well and that is what Jeffrey implemented here.

I'm not so much questioning which strategies this acceleration should use.  Based on our discussion and previous experience with this feature, it seemed likely that this will "mostly work".  But an inchoate "mostly working" is very frustrating in the context of a debugger.  So going along with this feature should be some sketch of the things that it doesn't support (do inline breakpoints always work?, what kinds of symbols are you likely not to find, etc, what trouble is this likely to cause to the expression parser and how would a user work around this).  This isn't an explanation so much for me as for users of the feature.  I don't think "This is mostly for users of GUI debuggers and they probably won't do anything that might get into trouble" is a good support strategy.  

> 
>> It also seems like there should be a way to say "These libraries I'm unlikely to care about, but these I always want to have fully expanded".
> 
> We were hoping to see if we can automagically make this stuff work well enough that it requires no settings, but we are happy to add these settings in subsequent patches. The patch is already large as it is. Let us know if these should be added with this initial patch. We might also think about asking the Platform layer if they have any libraries that they know should be always on.
> 
>> Normally, it would be fine to say "we can add those details as we go along" but you're designing a new mode of interaction with the debugger, and I think we need to sketch out what we think are acceptable tradeoffs and where we need to give people the ability to manually intervene, etc.  So it seems like we should first be having a strategy discussion, before getting down to the details of this patch.
> 
> We would love to setup a Video Chat with anyone interested if that would work. Talking back and forth on email or lists takes a while and I think we can easily hash things out if any interested parties are willing to attend. We are on Pacific time zone, anyone else that wants to participate, please chime in and we will see if we can set something up?!

This sounds fine, but I think as a starting point it would be good to have a list of what doesn't work with this approach.  Obviously getting hold of types is going to be a problem.  How far will that affect what people do?  For instance, on MacOS you think people just look at local variables but in fact they use "po" all the time so they are in fact fairly heavy users of the expression parser.  But these might be simple and local enough not to be a problem?  Once we have a good sense of where the tradeoffs are in this design, we can think about whether we need to do some mitigations for some of the issues, or whether we just need some more documentation to guide users along or whatever.

If something like this actually works, we're going to have to support it forever, and should realize that we will likely be dragged into making it actually just as good as the now unacceptably slow complete version.  So we need to go into this with our eyes open.

Jim

> 
> 
> Repository:
>  rG LLVM Github Monorepo
> 
> CHANGES SINCE LAST ACTION
>  https://reviews.llvm.org/D121631/new/
> 
> https://reviews.llvm.org/D121631
> 