[lldb-dev] Hiding local variables not defined yet

[Emre Kultursay via lldb-dev]

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 <emrekultursay at 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 <clayborg at gmail.com> wrote:
>
>>
>>
>> On Apr 9, 2021, at 11:39 AM, Emre Kultursay via lldb-dev <
>> lldb-dev at 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 at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20210412/3744264c/attachment.html>