Reputation: 1784
I have precise and validated descriptions of the behaviors of many X86 instructions in terms amenable to encoding in QF_ABV
and solving directly with the standard solver (using no special solving strategies). I wrote an SMT-LIB script whose interface matches my ultimate goal perfectly:
X86State
, a record sort describing x86 machine state (registers and flags as bitvectors, and memory as an array).X86Instr
, a record sort describing x86 instructions (enumerated mnemonics, operands as an ML-like discriminated union describing registers, memory expressions, etc.)x86-translate
taking an X86State
and an X86Instr
, and returning a new X86State
. It decodes the X86Instr
and produces a new X86State
in terms of the symbolic effects of the given X86Instr
on the input X86State
.It's great for prototyping: the user can write x86 easily and directly. After simplifying a formula built using the library, all functions and extraneous data types are eliminated, leaving a QF_ABV
expression. I hoped that users could simply (set-logic QF_ABV)
and #include
my script (alas, neither the SMT-LIB standard nor Z3 support #include
).
Unfortunately, by defining functions and types, the script requires theories such as uninterpreted functions, thus requiring a logic other than QF_ABV
(or even QF_AUFBV
due to the types). My experience with SMT solvers dictates that the lowest acceptable logic should be specified for best solving time. Also, it is unclear whether I can reuse my SMT-LIB script in a programmatic context (e.g. OCaml, Python, C) as I desire. Finally, the script is a bit verbose given the lack of higher-order functions, and my lack of access to par
leading to code duplication.
Thus, despite having accomplished my technical goals, I think that SMT-LIB might be the wrong approach. Is there a more natural avenue for interacting with Z3 to implement my x86 instruction description / QF_ABV
translation scheme? Is the SMT-LIB script re-usable at all in these avenues? For example, you can build "custom OCaml top-levels", i.e. interpreters with scripts "burned into them". Something like that could be nice. Or do I have to re-implement the functionality in another language, in a program that interacts with Z3 via a theory extension (C DLL)? What's the best option here?
Upvotes: 0
Views: 324
Reputation: 868
Well, I don't think that people write .smt2 files by hand. These are usually generated automatically by some program. I find the Z3 Python interface quite nice, so I guess you could give it a try. But you can always write a simple .smt2 dumper from any language.
BTW, do you plan releasing the specification you wrote for X86? I would be really interested!
Upvotes: 0