[lldb-dev] problems using EvaluateExpression in lldb, when it creates new object

[Greg Clayton via lldb-dev]

> On Jan 14, 2022, at 10:13 AM, fhjiwerfghr fhiewrgfheir via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> I'm sorry in advance, if it's not a correct mailing list, there doesn't seem to be lldb-usage mailing list.
> 
> I'm writing a pretty-printer python script, which - to cut to the chase, pretty prints members of a class by using EvaluateExpression and creating new object inside it. It doesn't seem to work - i'm getting "<could not resolve type>" error. Should my idea work in a first place and i't s a bug or it shouldn't and i need to find a different solution?

This might be a case where -flimit-debug-info, the default setting for things on linux, is getting in the way. Can you try specifying -glldb on the command line and see if that fixes things? The default case for linux is for the compiler to not emit debug info for types that might exist in other frameworks. This was an effort to reduce .o file sizes. In this case, you might be running into a case where the debug info for std::string_view is being emitted as a forward declarartion, so the expression parser can't end up using it. The best way to tell is to make a local "std::string_view" object that has valid contents and see if you can expand the variable in the debugger. I am not a fan of this approach of omitting debug info that the debugger needs, but it is unfortunately the default setting for linux compiles.


The other thing to mention is it is a really bad idea to run expressions as part of data formatters or summary providers. Why? Expressions can end up resuming all threads if the expression deadlocks for any reason or if the expression doesn't complete. Of course if you have properties that are generated, you don't have much of a choice, so try to only use expressions if you know the expression won't ever deadlock due to another thread holding a mutex or other locking mechanism. If you can, best to try and just access existing data within an object if at all possible.

> 
> I'm attaching a repro case:
> 
> clang++ q.cpp -g -o o -std=c++20
> lldb o
> command script import lldb_script.py
> br set --file q.cpp --line 19
> r
> print c
> 
> 
> it prints:
> (lldb) print c
> (C) $0 = CCC {
>    = <could not resolve type>
> }
> 
> it should something akin to:
> (lldb) print c
> (C) $0 = CCC {
>   b   = B {
>     a = A {
>       id = "qwerty"
>     }
>   }
> }
> 
> 
> 
> <q.cpp><lldb_script.py>_______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev