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

Tue Mar 15 15:45:28 PDT 2022

yinghuitan marked 2 inline comments as done.
yinghuitan added a comment.

Jim, Pavel, thanks for the comment!

I am happy to start a strategy discussion for this feature. @clayborg will chrime in later to suggest the approach how we can discuss.

I would like to answer some of the questions here to share some context.

> speed for visibility tradeoff

Right, that is the basic principle of this feature. We are designing this feature primarily targeting IDE use cases which, we found, majority of the users are focusing on several modules authored/depended by their own code. 
Also they primarily use basic subset features of lldb.

> They (and we) also need to know what operations might trigger a full "hydration" of a symbol table

We would like to make the feature work *by default* as much as possible so we decided to use breakpoint match, callstack and symbol table match to guide a module's debug info hydration. To direct answer this question: I haven't find a common case that can hydrate all process modules debug info yet unless there is callstack covering all modules or a function name matching in all module's symbol table while setting function breakpoint.

> whenever the user tells about a shared library, we should "hydrate" it

I agree. Since this feature is designed for IDE scenario so we haven't focused on covering all lldb commands when a module is specified. In "break set -s someLib.dylib -f foo.c -l 12" example, if there is a matching foo.c in someLib.dylib, it will be hydrated; otherwise not.

> 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".

I agree. It is in my plan to add a "symbols.on-demand-modules" setting which users can explicitly white list some modules for hydration.

> unify with `target.preload-symbols` feature

I do not have strong opinion on this. One concern is that `target.preload-symbols` provides full experience but `symbols.load-on-demand` provides trade-off experience (for example some global expression evaluation may fail because we won't automatically hydrate based on type query).

> I don't think that "run everything with the setting turned on" is a good testing strategy

I do not have strong opinion either. I understand the concern is extra test time. I do want to share that there are many tests that do not set breakpoints which exercised symbol ondemand code path and helped to catch real bugs in the implementation.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D121631/new/

https://reviews.llvm.org/D121631