teemperor added inline comments.
================ Comment at: lldb/source/Plugins/ExpressionParser/Clang/ASTResultSynthesizer.cpp:409 + // static MyClass *__lldb_expr_result_ptr = &c; // Points to stack. + // __lldb_expr_result_ptr(__lldb_expr_result_ptr); + // } // End of expression function. ---------------- vsk wrote: > vsk wrote: > > Why is it safe for lldb to take the address of "c"? After evaluation > > completes, is the state of the stack preserved? > Would marking `__lldb_expr_result_ptr` volatile make the call to > `__lldb_use_expr_result` redundant? That's actually a good point and I am actually writing up an RFC about the current behaviour to lldb-dev. The current behaviour of LLDB is that we end the function call, we call all the destructors and so on and then we read the results from memory. So the memory we read is just the leftovers after the function call has returned. That's why a unique_ptr local variable in LLDB always looks like it owns no memory because we read it after it got already destroyed. I'm actually thinking whether/how we should fix that behaviour as seems rather fragile (but that's for the RFC). So unless I'm missing something, we currently already rely on the stack being preserved to even get the correct results. The function call is just there to make sure the optimizer doesn't realize what we're up to. Not sure about the `volatile` and if it would help. The `__lldb_expr_result` variable gets transformed by IRForTarget until it ends up being just a part of our argument struct IIRC, so I need to look into that before I know where we could sneak in a volatile. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102624/new/ https://reviews.llvm.org/D102624 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
