-
Notifications
You must be signed in to change notification settings - Fork 41
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
RFC: crucible-llvm: Parameterize over memory and pointer types #1194
Draft
langston-barrett
wants to merge
6
commits into
GaloisInc:master
Choose a base branch
from
langston-barrett:lb/llvm-param-mem
base: master
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
RFC: crucible-llvm: Parameterize over memory and pointer types #1194
langston-barrett
wants to merge
6
commits into
GaloisInc:master
from
langston-barrett:lb/llvm-param-mem
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The idea is that we have a lot of big changes we'd potentially like to make to the memory model: - Issue no. 917: Decouple memory from control flow - Issue no. 404: Improve underlying symbolic type for pointer representation - Issue no. 399: Refactoring the memory model - Issue no. 366: Bit-level undef/poison The problem is that these are all very hard to get started on, because they would involve sweeping changes across Crucible-LLVM and all downstream packages. We could also consider alternative memory models for different use-cases: - A "flat" model based on a single SMT array with a bump allocator, to let the SMT solver handle more of the hairy details - A "lazy" model in the style of UC-KLEE for under-constrained symbolic execution - A "fresh" model that always returns fresh symbolic constants when read All of these would have interesting trade-offs, but can't effectively be explored at the moment. This commit is the first step in making it easier to run such experiments. The goal is to parameterize Crucible-LLVM over a typeclass that provides (Crucible and Haskell) types and operations on memory and pointers. To that end, it introduces a new `mem` type variable. At the moment, a lot of places in the code add the abstraction-breaking `mem ~ Mem` constraint. The goal would be to gradually add operations to the `Mem` class and remove such equality constraints. Some notable downsides: - Increased complexity. See e.g., the pattern matches in `Translation.Instruction`, which I couldn't figure out how to adequately replace. Counterpoint: programming against an well-defined interface (i.e., a typeclass) can reduce mental complexity by abstracting superfluous detail. - Code churn within Crucible - API churn for consumers Mostly done with: mogglo-haskell \ '${{ focus:kind() == "type" and not string.find(focus:parent():parent():text(), "mem") and focus:text() == "LLVM" }}' \ --replace '${{ "(LLVM mem)" }}'\ --confirm path/to/file.hs
Evaluation just assumes `mem ~ Mem`, but translation doesn't need very many operations.
@RyanGlScott Could you take a look and see if you like the direction this is headed? This still needs:
But at that point, I think it will be a self-contained first step towards parameterizing the memory model, the next steps being removing the |
Some initial thoughts:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Note that the code changes are very WIP. Further notes below.
The idea is that we have a lot of big changes we'd potentially like to
make to the memory model:
The problem is that these are all very hard to get started on, because
they would involve sweeping changes across Crucible-LLVM and all
downstream packages.
We could also consider alternative memory models for different
use-cases:
let the SMT solver handle more of the hairy details
execution
All of these would have interesting trade-offs, but can't effectively be
explored at the moment.
This PR is the first step in making it easier to run such
experiments. The goal is to parameterize Crucible-LLVM over a typeclass
that provides (Crucible and Haskell) types and operations on memory and
pointers.
To that end, it introduces a new
mem
type variable. At the moment, alot of places in the code add the abstraction-breaking
mem ~ Mem
constraint. The goal would be to gradually add operations to the
Mem
class and remove such equality constraints.
Some notable downsides:
Translation.Instruction
, which I couldn't figure out how toadequately replace. Counterpoint: programming against an well-defined
interface (i.e., a typeclass) can reduce mental complexity by
abstracting superfluous detail.
Notes on progress:
mem
type variable andMem
typeclass.Mem
, but evaluation just forcesmem
to be explicitly equal to the current memory model. More operations would be needed inside theMem
typeclass to make evaluation more parametric.