Looking at Android Studio implementation a little deeper, it actually does the filtering the way I described in my first email, by comparing line numbers. It does not use the location expressions.
Do you have a pointer to another implementation (e.g., lldb-vscode) that filters based on location expressions, for comparison? On Mon, Apr 12, 2021 at 12:31 PM Emre Kultursay <emrekultur...@google.com> wrote: > LLDB does only show variables that are in lexical scope in ... > > Ah, yes, I got confused because I thought this filter was implemented > inside LLDB, yet the `frame variable` command was returning me all local > variables; I now notice that it's a filter that's implemented inside the > IDE (I'm looking at Android Studio). > > Thanks for the explanation and also the details about the compiler > provided info. > > > On Fri, Apr 9, 2021 at 10:15 PM Greg Clayton <clayb...@gmail.com> wrote: > >> >> >> On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >> When debugging C/C++ (statically scoped languages), does LLDB recognize >> (or does it have a setting for it) that a local variable is not defined yet >> at the current program address (i.e., DW_AT_decl_line is less than the >> source line for the address), and thus, not include it in the list of >> locals (i.e., frame variable)? >> >> Does it make sense to have such a setting? The goal is to reduce the >> clutter in locals list. >> >> >> LLDB does not. We show exactly what the compiler emits. DWARF, the debug >> information, is powerful enough to say from [0x1000-0x1010) the variable is >> here, and from [0x1020-0x1100) the variable is there, these are called >> location expressions. But the compiler, for non optimized code, always just >> emits the variable's location on the stack and doesn't correctly limit it >> to when the variable has been initialized. >> >> So this could easily be fixed in the compiler. LLDB really needs to >> listen to what the compiler says because once you enable optimizations, the >> compiler can end up moving all sorts of code around and the variable >> _could_ become initialized before the DW_AT_decl_line. >> >> So we don't want to pretend we know better than the compiler when >> displaying debug information. But even if the compiler does emit better >> debug information that does give correct location expressions, we would >> still show the variable because it is in scope. LLDB does only show >> variables that are in lexical scope currently in Xcode, lldb-vscode, lldb, >> and Android Studio AFAIK. What debugger are you using? >> >> Greg >> >> >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> >>
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
