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. > 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?! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D121631/new/ https://reviews.llvm.org/D121631 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
