Can it handle self-modifying code?
Why only x86_64? It has more sense to convert 32-bit programs, like many old games.
I think self-modifying outside of JIT runtimes is a pretty rare thing these days compared to the 80s or 90s, .text sections are mostly RO these days and security requirements aren't going to decrease that.
On the greenfield x86 development side: Self-modifying code, while possible, is generally terrible because it obliterates cache lines and pipeline branch prediction performance too. And it also violates W^X so it generally has to be used in JIT-compatible memory pages. So avoid it almost always. It was kind of a thing in 486 and P5 days like using code immediates as inner loop variables, but not so much now.
There's a lot of x86 crufty edge-cases to handle to achieve perfect(ish) emulation or translation.
Why doesn't it clean my garage also? I've got some leaves to rake as well.
> Can it handle self-modifying code
If it did, it wouldn't be "fully static" anymore. It's fundamentally contradictory.
[dead]
Consider reading the linked article, where this is explicitly addressed:
> Self Modifying and JIT-Compiled Code. Elevator, like all fully static binary rewriters, does not support self modifying or just-in-time-compiled code.