When I build the plugin against an LLVM, that is configured without support for the host target, then string obfuscation cannot JIT-compile the encode() routine during at compile-time. That's expected behavior. Unfortunately, the error isn't helpful right now:
/Applications/Xcode_15.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -S -emit-llvm -target aarch64-unknown-linux-android-O1 -std=c++17 -mllvm --opaque-pointers -o /var/folders/2k/myk8kt8d4f52dzr19331wtxr0000gn/T/lit-tmp-1s5r_xy6/omvll-aarch64-unknown-linux-android-O1-1af1b7.cpp.ll /var/folders/2k/myk8kt8d4f52dzr19331wtxr0000gn/T/lit-tmp-1s5r_xy6/omvll-aarch64-unknown-linux-android-O1-1af1b7.cpp
Unable to find target for this triple (no targets are registered)
This is confusing because:
no targets are registered is wrong (it had AArch64). The problem is that we don't have the target for the requested triple (X86 in this case).
The requested triple isn't dumped in the error message, so it's not clear which specific target is missing.
It seems that the error happens before we dump the respective command. That way it looks like the previous command is the one that failed. (The one with the AArch64 triple above.)
The error is dumped from LLVM itself, so improving (2) might need an extra check upfront in OMVLL. Note that this might be hard to reproduce on a Apple Silicon machine.
When I build the plugin against an LLVM, that is configured without support for the host target, then string obfuscation cannot JIT-compile the
encode()routine during at compile-time. That's expected behavior. Unfortunately, the error isn't helpful right now:This is confusing because:
no targets are registeredis wrong (it had AArch64). The problem is that we don't have the target for the requested triple (X86 in this case).AArch64triple above.)I think the target-check is done when constructing the host-JIT inside
StringEncoding::genRoutines(): https://github.com/open-obfuscator/o-mvll/blob/c10c275de16af1a3a3d5eca0112b69aebf0337f6/src/passes/strings-encoding/StringEncoding.cpp#L556The error is dumped from LLVM itself, so improving (2) might need an extra check upfront in OMVLL. Note that this might be hard to reproduce on a Apple Silicon machine.