Many ABIs impose some kind of alignment constraints on the stack
pointer. For example, both the AArch32 and x86_64 SysV ABIs specify
that the end of the spilled argument list is aligned to 2*w where w
is the number of bytes in a word. Since macaw-symbolic has no notion
of the ABI in use, its ABI-agnostic code could only ever satisfy such
alignment constraints accidentally. Clients wishing to spill arguments
to the stack should do so with ABI-specific functionality.
There was a lot of redundant unwrapping and re-wrapping of the
assignment of `TypeRepr`s to the architecture register context into and
out of a `StructRepr`. Remove this.
Also, add an hlint configuration file to help avoid this in the future,
and a Github Actions workflow to enforce this in CI.
dbb4c83 introduced this stack-pointer-in-the-middle approach, but
the commit message has no further commentary on why it was seen as
necessary. I've written up why *I* believe it to be necessary, and
removed what I see as a misleading comment.
Also, return a pointer to the end of the stack, because that's what
most clients will want.
This bumps the `what4` submodule to the 1.6.* version series and updates the
`.cabal` files in the `macaw` repo accordingly.
Bumping the `what4` submodule also requires bringing in corresponding changes
in the `crucible`, `llvm-pretty`, and `llvm-pretty-bc-parser` submodules, so I
have done that as well.
This introduces a `HasMacawLazySimulatorState` data type, which provides a
"classy lens" for accessing a `MacawLazySimulatorState` within some Crucible
personality type. It also generalizes the lazy `macaw-symbolic` memory model in
`Data.Macaw.Symbolic.Memory.Lazy` to be polymorphic over
`HasMacawLazySimulatorState` instances. The upside is that it is now possible
to use the lazy memory model at other personality types besides just
`MacawLazySimulatorState`, making it much easier to extend the memory model.
Because there is a `HasMacawLazySimulatorState` instance for
`MacawLazySimulatorState`, existing code that uses `MacawLazySimulatorState`
should continue to compile without changes.
Fixes#357.
Rather than `error`ing, we now generate fresh constants for all possible
`macaw` `Type`s that are supplied to the `MacawFreshSymbolic` operation.
Fixes#301.
This patch contains a handful of tweaks needed to make the libraries in the
`macaw` repo build with GHC 9.6:
* GHC 9.6 bundles `mtl-2.3.*`, which no longer re-exports `Control.Monad`,
`Control.Monad.Trans`, and similar modules from `mtl`-related modules. To
accommodate this, various imports have been made more explicit.
* I have disambiguated a use of `Data.Parameterized.NatRepr.withKnownNat` in
`macaw-aarch32` to avoid clashing with a newly exported function of the same
name in `GHC.TypeNats`.
* I have bumped various upper version bounds on `doctest`,
`optparse-applicative`, and `what4` to allow building these libraries with
GHC 9.6.
* I have bumped the following submodules to bring in GHC 9.6–related changes:
* `asl-translator`: GaloisInc/asl-translator#53
* `crucible`: GaloisInc/crucible#1102
* `dwarf`: GaloisInc/dwarf#6
* `elf-edit`: GaloisInc/elf-edit#38
* `flexdis86`: GaloisInc/flexdis86#54
* `grift`: GaloisInc/grift#9
* `llvm-pretty`: elliottt/llvm-pretty#112
* `llvm-pretty-bc-parser`: GaloisInc/llvm-pretty-bc-parser#225
* `semmc`: GaloisInc/semmc#80
* `what4`: GaloisInc/what4#235
The only other changes required are (1) deleting an unused dependency on
`what4-serialize`, and (2) raising upper version bounds on `what4`.
This brings in submodule changes from the following:
* GaloisInc/asl-translator#48, which performed a similar `what4` adaptation.
* GaloisInc/semmc#78, which performed a similar `what4` adaptation.
* GaloisIns/crucible#1068, which ensures that everything can build against
`tasty-sugar >= 2.0` (the version of the library that `what4-1.4` depends on).
This folds the menagerie of various configuration option arguments to
`macawExtensions` into the `MemModelConfig` data type. The advantage to doing
this is that is will make it easier to extend the memory model configuration
options in the future without needlessly foisting breaking changes on all
`macaw-symbolic` users.
Unfortunately, it does require a breaking change to get to this point, but the
migration path is straightforward for existing code. I have included this
migration story in the `macaw-symbolic` changelog.
The current `macaw-symbolic` memory model has issues when scaling up to
binaries that have several megabytes or more in size. This patch introduces a
new memory model (in `Data.Macaw.Symbolic.Memory.Lazy`) that serves as a mostly
drop-in replacement for the existing memory model (which I now refer to as the
"default" memoy model). The lazy memory model scales better by incrementally
populating the SMT array backing global memory over the course of a run of the
simulator. For the full details, see `Note [Lazy memory model]`.
I performed some refactoring to share common bits between the default and lazy
memory models.
Fixes#282.
This patch introduces a `MemModelConfig` data type for configuring the finer
details of `macaw-symbolic`'s memory model. For now, there is a single option,
which configures whether the memory model should attempt to concretize pointers
during a read or write, which can sometimes be beneficial for performance
reasons. The details of how concretization work can be found in the new
`Data.Macaw.Symbolic.Concretize` module.
Subsequent commits will add more configurable knobs to `MemModelConfig`.
Fixes#323.
This extends `Data.Macaw.Symbolic.Testing` in `macaw-symbolic` to be able to
handle binaries that depend on shared libraries. This is fully functional for
the x86-64 and AArch32 symbolic backends, and I have added test cases to the
respective repos demonstrating that it works. (The PowerPC backend is not yet
supported. At a minimum, this is blocked on GaloisInc/elf-edit#35.)
To implement this, I also needed to add some additional infrastructure to
`macaw-base` (I put this infrastructure here as it doesn't depend on any
Crucible-specific functionality):
* `Data.Macaw.Memory.ElfLoader.DynamicDependencies`: a basic ELF dynamic
loader that performs a breadth-first search over all `DT_NEEDED` entries
that an ELF binary depends on (both directly and indirectly).
* `Data.Macaw.Memory.ElfLoader.PLTStubs`: a collection of heuristics for
detecting the addresses of PLT stubs in a dynamically linked binary.
It is worth noting that shared libraries are rife with nuance and subtlety,
and the way `macaw` models shared libraries is not 100% accurate. I have
written a length `Note [Shared libraries]` in `Data.Macaw.Symbolic.Testing`
to describe where corners had to be cut.
Fixes#318.
When populating `COPY` relocations, it is helpful to know the address of the
relocation so that it can be related back to the name of the global symbol
whose value it is copying. Unfortunately, the type of `populateRelocation` does
not make it straightforward to compute this address. This patch includes three
additional arguments to `populateRelocation` (the relocation's `Memory`, its
`MemSegment`, and its `MemAddr`) to more easily facilitate computing the
address.
This is a breaking API change, albet it is a fairly straightforward change to
adapt to for most consumers.
This is related to #47, although this is not a full fix for the issue.
This patch was motivated by the need to call `doGetGlobal` from a Crucible
override, where the `SimState` is instantiated with `OverrideLang` rather than
`CrucibleLang`, the latter of which is used in the `CrucibleState` type
synonym. While I was in town, I generalized the types of other operations in
`Data.Macaw.Symbolic.MemOps` where it was reasonable.
