[Lldb-commits] [PATCH] D94077: Support unscoped enumeration members in the expression evaluator.

[Jim Ingham via Phabricator via lldb-commits]

jingham added a comment.

In D94077#2486225 <https://reviews.llvm.org/D94077#2486225>, @werat wrote:

> In D94077#2479984 <https://reviews.llvm.org/D94077#2479984>, @shafik wrote:
>
>> We can have unscoped enums in namespace and class scope and the enumerators won't leak out from those scopes. Thus we can have shadowing going on e.g.:
>>
>> ...
>>
>> How does this change deal with those cases?
>
> Thanks for pointing this out! My first patch didn't really take this into account, so it didn't work properly. I've made some changes to make it work, although I'm not very familiar with these parts of LLDB yet, so I'm not sure whether this approach is how it should be implemented.
>
> Also I've noticed that LLDB's expression evaluator is not perfect with these lookups, e.g. it can find global variables from other scopes if there's no better candidate (not sure if this is a bug of a feature):
>
>   Process 3768045 stopped
>   * thread #1, name = 'a.out', stop reason = breakpoint 1.1
>       frame #0: 0x0000000000401116 a.out`main at global.cpp:2:13
>      1    namespace Foo { int x = 1; }
>   -> 2    int main() {};
>   (lldb) p x
>   (int) $0 = 1

That's a feature, not a bug.  lldb tries to find the "closest" definition to the frame in which the expression is evaluated, it isn't bound by what the current frame can see.  If it can find a unique closest definition for an identifier working out from the current frame, it will that.

This seems the most useful behavior.  If your program has a shared library that has a static singleton which stores some interesting information about the library's state, debugger users want to be able to access that variable in the expression evaluator even if they aren't currently stopped in a frame of that library.  That's also important for type lookups.  If I'm in a frame of library A, which only sees a forward declaration of some type, but library B has the full debug information for that type, it's super useful to be able to keep looking past library A for a full type definition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94077