Current situation and future plan on porting and future compatibility

[Naville]

Background

When I started the project back in 2017, related LLVM API/ABIs are relatively stable, so I used quite some hacks to speed up the whole process and uses a custom scheduler to precisely control the whole obfuscation pipeline. This approach survived three major LLVM releases (6.0/7.0/8.0) which by LLVM standard is roughly a year and a half.

Status

Starting from LLVM9 the internal Pass Manager structure went a major update, broke the mechanism that our custom pass scheduler depends on. Since many Obfuscation passes internally assumes our pass scheduler works as-is, merely fixing the pass scheduler mechanism won't work well. There are temporary workarounds for this issue however from personal experience they are not stable and is even more of a hack. All those changes require some dedicated work to Hikari, sometimes even involve rewriting some passes (which is something I have planned for a long time but never really bothered)

Future plan and schedule

The current plan is to rewrite some passes and switch to the more LLVM-standard methods of doing things. This would OBVIOUSLY provide lots of benefits including better future LLVM compatibility. With Swift5.2 at the corner which uses LLVM9 and contains proper arm64e support, this plan is almost a must. This rewrite would also allows us to handle other Swift stuff better and could serve as a drop-in replacement for Apple Clang.
tl;dr:

• Linux release
• Stable macOS/Xcode release based on Apple Clang that provides drop-in replacement for the Xcode toolchain and arm64e support while supporting the same set of language features as Apple does, avoiding issues like #82

Bad news

Unfortunately this would OBVIOUSLY takes quite some work and a large part of my personal time. Consider I can't actually (and haven't) earned a single penny from it, I personally isn't gonna dedicate that much effort into it and would rather do it when I have the mood and time for it. All these means this port would probably takes at least a full calendar year.
To make things worse for my current laptop, compiling the LLVM suite takes ~1.5 hours and 4hours for the full Swift toolchain and takes ~60GB of disk space for debugging which I just don't have. As a result even if I got the port working, initial releases would only contain Linux executables, which is the OS my current HEDT workstations runs on.