[Lldb-commits] [PATCH] D91508: [LLDB/Lua] add support for one-liner breakpoint callback
Pedro Tammela via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Nov 23 14:47:30 PST 2020
tammela added a comment.
> I'm not sure what you mean by that. Can you elaborate?
Sure, it's was just a nod to your previous comment about that running callbacks (C++ lambdas) inside a `pcall` is a dangerous API. Although possible, it requires that the developer be very cautious about implicit throws.
> The way I see it, the problem is not about which environment is the c++ code running in, as it can't throw an exception (in llvm). The problem is what happens when we call lua from c++, and the lua code throws. And this is a problem regardless of the environment the C(++) code is in -- the difference is "only" in whether lua will panic or jump over the C code, but something bad will happen anyway.
I agree 100% with your analysis of the problem.
> I think that could be solved by ensuring we always call lua in a protected environment. That way lua will never unwind through the C code (regardless of what environment it is in) because it would always stop right at the boundary.
>
> That would essentially mean, lua_call is banned (except maybe as an optimization, if you can be sure that the code you're about to call will not throw), and all C->lua transitions should go through lua_pcall. And we can provide a wrapper that handles catches those errors and converts them to llvm::Error/Expected, similar to how the python things do it.
I have posted a redesign based on your comments. The `lua_push*` functions are all safe-ish. The Lua implementation guarantees at least 20 stack slots when the `lua_State` is created so I've added the stack checks for sanity rather than necessity.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D91508/new/
https://reviews.llvm.org/D91508
More information about the lldb-commits
mailing list