ahmedbougacha
commented
7 years ago Is the LLVM IR output of dagger supposed to be compilable?
Yes
It seems that for every binary I lift into IR, dagger inserts an llvm.dc.translate.at intrinsic. When I recompile the LLVM IR file, llc complains about this intrinsic (same issue with lli). I am using the llc/lli built from the dagger fork
The translate_at intrinsic means that program control flow isn't statically resolvable (i.e., when looking at most indirect branches, we don't know where we're going to jump next just by looking at the binary).
The dynamic translation runtime (DYN) is the only way to solve this problem in the general case. It replaces translate_at calls to runtime translation helpers that do the translation and recompilation just-in-time, with the then-available branch target.
However, there are ways to approximate the indirect branches: for instance, I experimented with lowering translate_at with a lookup table that dynamically resolves program addresses to already-known statically-translated functions. (that solves indirect calls if you have symbols/LC_FUNCTION_STARTS/etc..). I also experimented with a transformation that understands jump tables (mainly using the LVI machinery in upstream llvm), and that should solve a lot of indirect branches. I can push some crude patches if you're interested.
Sorry for the belated reply, let me know if you have more questions!
Is the LLVM IR output of dagger supposed to be compilable? It seems that for every binary I lift into IR, dagger inserts an llvm.dc.translate.at intrinsic. When I recompile the LLVM IR file, llc complains about this intrinsic (same issue with lli). I am using the llc/lli built from the dagger fork.