Re: State of decompilers for lua?

[tehtmi <tehtmi@...>]

Hi,

I'm the author of unluac, a popular Lua decompiler.

> In short, what is the state of decompilers
>         for Lua such and for Lua version 5.4?

Unluac supports Lua 5.4. I consider unluac to be very good for all supported versions (5.0+) as long as it has debug info (and the bytecode is output of the normal PUC-Rio compiler). Most files (especially "real" files) can be decompiled perfectly (meaning re-compiling will give back the exact original file except for line numbers). Probably the main deficiency in this context is with "goto" which I think most people don't use in a way that unluac doesn't support. (This is not really a problem that should be hard to solve; I just haven't gotten around to it.)

> Has Lua bytecode or its compilation
>         changed significantly?
      It was overall pretty easy to add 5.4 support to unluac. There are
      a lot of new and changed opcodes in Lua 5.4, but hardly any of
      them really do anything new. TBC is maybe the main new thing in
      the bytecode, and it didn't seem that hard to deal with. Other
      issues were probably pretty specific to unluac's implementation,
      or esoteric.

> complex branching
      I have no basis to compare with Python, but I looked at some of
      your stuff. Using a parser to decompile control structures is
      interesting, and I can see some appeal, although I would have to
      dig in a lot more about it to figure out if it would actual solve
      any of the really difficult issues.

Lua does have some "branch optimization," and this is indeed one of the things that causes the most trouble in decompiling control flow. This can interact with "break" and other unconditional jumps (like "else," "goto" (when it is supported), and also jumps that are evidence of loops or conditionals that have otherwise been optimized out), and this is probably the largest case of complexity.