[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