Open RyanGlScott opened 2 years ago
After quite a bit of investigation, it seems likely that the issue lies in the way macaw-semmc
converts the translated What4 expressions into Macaw. In particular, the semantics for the LDM
instruction always add this ReadMem
assignment, which is later passed to a Mux
:
val_aVCFX <- let
memRep_aVCFV
= (MC.BVMemRepr (S.knownNat :: S.NatRepr 4)) MC.LittleEndian
assignGen_aVCFW
= GHC.Base.join
(Data.Macaw.SemMC.Generator.addAssignment
<$>
((MC.ReadMem <$> pure val_aVCFU)
<*> pure memRep_aVCFV))
in (MC.AssignedValue <$> assignGen_aVCFW)
val_aVCFY <- ((Data.Macaw.ARM.Semantics.ARMSemantics._df_df_getSlice_4N_32length_1_norm
val_aVCFX)
lval_aVCEi)
lval_aVCFf
val_aVCFZ <- Data.Macaw.SemMC.TH.addApp
((MC.Eq lval_aVCEh) val_aVCFY)
let lval_aVCG0
= (Data.Macaw.SemMC.TH.bvValue (S.knownNat :: S.NatRepr 1)) 0
val_aVCG1 <- Data.Macaw.SemMC.TH.addApp
((((MC.Mux (MT.BVTypeRepr (S.knownNat :: S.NatRepr 1)))
val_aVCFZ)
lval_aVCEh)
lval_aVCG0)
If you go far back enough in the generated code, you'll find that this particular Mux
's condition concretely evaluates to false, so in theory, the ReadMem
shouldn't be needed. But the ReadMem
assignment is added anyway, since the addAssignment
function is eagerly invoked using a monadic bind. Ugh.
I've tried lots of different tweaks in the macaw-semmc
code generator to make things lazier, but nothing quite seems to work.
Consider this C program, appropriately decorated for use in
macaw
's test suite:Compile this program with the an AArch32 version of
musl-gcc
:Now run this test harness on
bug.exe
(the code was extracted frommacaw-aarch32-symbolic
's test suite):If you run this, it will unexpectedly fail:
Note that if you change the array to be of a smaller length, e.g.,
Then the test will pass.
@travitch suspects that the issue may arise from
macaw-symbolic
's interval logic here.