Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x86-symbolic: Setting up a SysV-compatible stack #433

Merged
merged 22 commits into from
Sep 17, 2024
Merged
Show file tree
Hide file tree
Changes from 21 commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
9955200
x86-symbolic: Setting up a SysV-compatible stack
langston-barrett Sep 3, 2024
ffcab1c
x86-symbolic: A module for SysV stack manipulation
langston-barrett Sep 4, 2024
e947585
x86-symbolic: More SysV stack setup and manipulation
langston-barrett Sep 4, 2024
145e005
x86-symbolic: Sort imports
langston-barrett Sep 4, 2024
c68cda0
symbolic: Remove unused LANGUAGE pragmas
langston-barrett Sep 4, 2024
f3fd0e0
symbolic: Small refactoring in `Testing` module
langston-barrett Sep 4, 2024
0c5ed97
symbolic: Rename and move a helper function in `Testing`
langston-barrett Sep 4, 2024
820401d
symbolic: Factor out fresh register assignment generator
langston-barrett Sep 4, 2024
c65ad34
symbolic: Data type for `(mem, mmConf)` tuple
langston-barrett Sep 4, 2024
6fcdb93
symbolic: Pass initial memory into `simulateFunction` as an argument
langston-barrett Sep 4, 2024
2372f69
symbolic: Factor out construction of initial registers and stack
langston-barrett Sep 4, 2024
2033a7d
symbolic: Further split up `simulateFunction`
langston-barrett Sep 4, 2024
be0a57f
symbolic: Don't feed the stack pointer to the `ResultExtractor`
langston-barrett Sep 5, 2024
ec0b522
symbolic: Further split up `simulateAndVerify`
langston-barrett Sep 6, 2024
9f2da79
symbolic: Try proving *all* safety conditions
langston-barrett Sep 6, 2024
ce96ba9
symbolic: Factor out simulation of discovered functions
langston-barrett Sep 11, 2024
672e0c5
symbolic: Generalize and simplify `simMacawCfg`
langston-barrett Sep 11, 2024
d005b9c
symbolic: More refactoring of testing code
langston-barrett Sep 11, 2024
b37e907
symbolic: Remove redundant constraints in testing code
langston-barrett Sep 11, 2024
edc9635
x86-symbolic: Use SysV-compatible stack setup in test suite
langston-barrett Sep 11, 2024
f80b275
symbolic: Sort imports
langston-barrett Sep 11, 2024
e1886a8
symbolic: Address review comments
langston-barrett Sep 12, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion macaw-aarch32-symbolic/tests/Main.hs
Original file line number Diff line number Diff line change
Expand Up @@ -106,7 +106,7 @@ armResultExtractor :: ( CB.IsSymInterface sym
)
=> MS.ArchVals MA.ARM
-> MST.ResultExtractor sym MA.ARM
armResultExtractor archVals = MST.ResultExtractor $ \regs _sp _mem k -> do
armResultExtractor archVals = MST.ResultExtractor $ \regs _mem k -> do
let re = MS.lookupReg archVals regs (MAR.ARMGlobalBV (ASL.knownGlobalRef @"_R0"))
k PC.knownRepr (CS.regValue re)

Expand Down
2 changes: 1 addition & 1 deletion macaw-aarch32-symbolic/tests/README.org
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
* Overview
This test suite tests that symbolic execution of AArch32 programs works. It is also a convenient place to test the semantics. The test harness looks for binaries in the ~pass~ and ~fail~ subdirectories. In both cases, it enumerates the functions whose names are prefixed by ~test_~, each of which are symbolically executed with fully symbolic initial states. It treats the return value of each test function as an assertion that it will attempt to prove (i.e., it checks the satisfiability of the assertion). Test cases in ~pass~ are expected to return a value that is always true, while the test cases in ~fail~ are expected to not always be true (but note that the precise models are not inspected). The test harness uses yices for path satisfiability checking and z3 to prove goals. Since path satisfiability checking is enabled, test cases can include loops as long as they symbolically terminate.

In addition to proving that the result of a test case is always true (or not), the test harness will attempt to prove all generated side conditions for tests with names prefixed by ~test_and_verify_~. In both the ~pass~ and ~fail~ directories, these side conditions are expected to pass (or they will cause test failures).
In addition to proving that the result of a test case is always true (or not), the test harness will attempt to prove all generated side conditions. In both the ~pass~ and ~fail~ directories, these side conditions are expected to pass (or they will cause test failures).
langston-barrett marked this conversation as resolved.
Show resolved Hide resolved

* Usage

Expand Down
2 changes: 1 addition & 1 deletion macaw-ppc-symbolic/tests/Main.hs
Original file line number Diff line number Diff line change
Expand Up @@ -118,7 +118,7 @@ ppcResultExtractor :: ( arch ~ MP.AnyPPC v
)
=> MS.ArchVals arch
-> MST.ResultExtractor sym arch
ppcResultExtractor archVals = MST.ResultExtractor $ \regs _sp _mem k -> do
ppcResultExtractor archVals = MST.ResultExtractor $ \regs _mem k -> do
let re = MS.lookupReg archVals regs (MP.PPC_GP (DP.GPR 3))
k PC.knownRepr (CS.regValue re)

Expand Down
2 changes: 1 addition & 1 deletion macaw-ppc-symbolic/tests/README.org
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
* Overview
This test suite tests that symbolic execution of PowerPC programs works. It is also a convenient place to test the semantics. The test harness looks for binaries in the ~pass~ and ~fail~ subdirectories. In both cases, it enumerates the functions whose names are prefixed by ~test_~, each of which are symbolically executed with fully symbolic initial states. It treats the return value of each test function as an assertion that it will attempt to prove (i.e., it checks the satisfiability of the assertion). Test cases in ~pass~ are expected to return a value that is always true, while the test cases in ~fail~ are expected to not always be true (but note that the precise models are not inspected). The test harness uses yices for path satisfiability checking and z3 to prove goals. Since path satisfiability checking is enabled, test cases can include loops as long as they symbolically terminate.

In addition to proving that the result of a test case is always true (or not), the test harness will attempt to prove all generated side conditions for tests with names prefixed by ~test_and_verify_~. In both the ~pass~ and ~fail~ directories, these side conditions are expected to pass (or they will cause test failures).
In addition to proving that the result of a test case is always true (or not), the test harness will attempt to prove all generated side conditions. In both the ~pass~ and ~fail~ directories, these side conditions are expected to pass (or they will cause test failures).

* Usage

Expand Down
2 changes: 1 addition & 1 deletion macaw-riscv-symbolic/tests/Main.hs
Original file line number Diff line number Diff line change
Expand Up @@ -109,7 +109,7 @@ riscvResultExtractor :: ( arch ~ MR.RISCV rv
)
=> MS.ArchVals arch
-> MST.ResultExtractor sym arch
riscvResultExtractor archVals = MST.ResultExtractor $ \regs _sp _mem k -> do
riscvResultExtractor archVals = MST.ResultExtractor $ \regs _mem k -> do
let re = MS.lookupReg archVals regs MR.GPR_A0
k PC.knownRepr (CS.regValue re)

Expand Down
2 changes: 1 addition & 1 deletion macaw-riscv-symbolic/tests/README.org
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
* Overview
This test suite tests that symbolic execution of RISC-V programs works. It is also a convenient place to test the semantics. The test harness looks for binaries in the ~pass~ and ~fail~ subdirectories. In both cases, it enumerates the functions whose names are prefixed by ~test_~, each of which are symbolically executed with fully symbolic initial states. It treats the return value of each test function as an assertion that it will attempt to prove (i.e., it checks the satisfiability of the assertion). Test cases in ~pass~ are expected to return a value that is always true, while the test cases in ~fail~ are expected to not always be true (but note that the precise models are not inspected). The test harness uses yices for path satisfiability checking and z3 to prove goals. Since path satisfiability checking is enabled, test cases can include loops as long as they symbolically terminate.

In addition to proving that the result of a test case is always true (or not), the test harness will attempt to prove all generated side conditions for tests with names prefixed by ~test_and_verify_~. In both the ~pass~ and ~fail~ directories, these side conditions are expected to pass (or they will cause test failures).
In addition to proving that the result of a test case is always true (or not), the test harness will attempt to prove all generated side conditions. In both the ~pass~ and ~fail~ directories, these side conditions are expected to pass (or they will cause test failures).

* Usage

Expand Down
Loading