Re: Bytecode differences between v1 and v2?
- From: Petri Häkkinen <petrih3@xxxxxxxxx>
- To: luajit <luajit@xxxxxxxxxxxxx>
- Date: Sat, 2 Jan 2021 00:32:56 +0200
On 31 Dec 2020, at 13.41, Mike Pall <mikelj-2012@xxxxxxx> wrote:
It's probably easier to decompile and recompile the files. There
are some bytecode decompilers floating around. Not sure whether
they handle all control-flow constructs correctly, though.
Unfortunately using a decompiler is not good solution in my case. The bytecode
to be patched is actually stored in savegames,
so I would have to include the decompiler in the executable. The best
decompiler that I'm aware of is written in Python, and I would rather not embed
a Python interpreter... If I went that route, I'd rather write a decompiler in
Lua myself but that would be a much bigger project.
So I've been thinking about another approach: I could patch
CALL/CALLT/CALLM/CALLMT opcodes to jump to stubs added to the end of each
prototype.
For example, the stub for a CALL would work like this:
1. Copy function to a new slot S
2. Copy arguments to slots S+2, S+3, ... (S+1 = gap)
3. Call the original function
4. Copy return values back to original slots
5. Jump back to the main program, to the instruction after the original CALL
CALLT, CALLM and CALLMT would have slightly different stubs. Naturally frame
size would be incremented to account for the new slots. This approach would of
course have performance implications, but I'm more interested in correctness
and feasibility of implementation at this point.
I'm still working out the details, but does this sound reasonable?
Do ITERC and ITERN also need a gap in FR2 mode? Any other instructions that
need special treatment?
Petri
Other related posts:
