<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Apr 12, 2021, at 4:44 PM, Emre Kultursay <<a href="mailto:emrekultursay@google.com" class="">emrekultursay@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small">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.</div></div></div></blockquote><div><br class=""></div>Interesting if they are doing more to hide variables. Most people debug with debug builds without optimizations, so most of the time this will be ok. If you end up debugging optimized code, I guess your variables could end up being hidden even though they are available and could have valid values.</div><div><br class=""></div><div>lldb command line, Xcode and lldb-vscode will do what I describe below when showing variables.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">Do you have a pointer to another implementation (e.g., lldb-vscode) that filters based on location expressions, for comparison?</div></div></div></blockquote><div><br class=""></div>We always show variables that are in scope. The debug information contains descriptions of functions and lexical blocks within functions. So when we have a PC address, we find the deepest lexical block and show its variables and all variables from all parent lexical blocks all the way back to the function. When there is a location expression for a variable, you will still see the variable, but the value might show an error saying that the variable is not available.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small"> <br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 12, 2021 at 12:31 PM Emre Kultursay <<a href="mailto:emrekultursay@google.com" class="">emrekultursay@google.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr" class=""><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">LLDB does only show variables that are in lexical scope<span class="gmail_default" style="font-size:small"> in </span>...<span class="gmail_default" style="font-size:small"></span></blockquote><div class="gmail_default" style="font-size:small">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). </div><div class=""><span class="gmail_default" style="font-size:small"></span> </div><div class=""><div class="gmail_default" style="font-size:small">Thanks for the explanation and also the details about the compiler provided info.</div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Apr 9, 2021 at 10:15 PM Greg Clayton <<a href="mailto:clayborg@gmail.com" target="_blank" class="">clayborg@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small">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)? <br class=""></div><div class="gmail_default" style="font-size:small"><br class=""></div><div class="gmail_default" style="font-size:small">Does it make sense to have such a setting? The goal is to reduce the clutter in locals list.</div></div></div></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Greg<br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:small"><br class=""></div></div>
_______________________________________________<br class="">lldb-dev mailing list<br class=""><a href="mailto:lldb-dev@lists.llvm.org" target="_blank" class="">lldb-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br class=""></div></blockquote></div><br class=""></div></blockquote></div>
</blockquote></div>
</div></blockquote></div><br class=""></body></html>