riscv64: Restore the IR types 7576d04 widened - #90
Open
zardus wants to merge 1 commit into
Open
Conversation
IRStmt_LLSC's result is Ity_I1 whenever storedata is non-NULL; pub/libvex_ir.h states it and guest_arm64_toIR.c builds the same store-conditional that way. Widening the temp to Ity_I64 made the statement fail the IR sanity check, so sc.w and sc.d stopped decoding at all. feq and flt assign an Ity_I1 comparison into the Ity_I32 temp they share with fle, which wraps its own comparisons in Iop_1Uto32. They now do the same, in both the F and the D extension. All six forms reported Ijk_NoDecode with size 0 before this; a RISC-V block that runs into one becomes undecodable bytes, and angr's linear scan restarts inside the instruction. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
THIS MESSAGE WAS GENERATED BY AN AUTOMATED PROCESS
7576d04("riscv: fix instructions that use the unsupported Ity_1 data type") widened threeIty_I1temporaries toIty_I64/Ity_I32without adapting what is assigned to them, so sixinstruction forms now fail the IR sanity check and libVEX reports the whole block as
Ijk_NoDecode:sc.w/sc.d.IRStmt_LLSC's result type is fixed by the IR contract:pub/libvex_ir.hsays "STOREDATA != NULL (SC): transfer type = type of STOREDATA, andRESULT :: Ity_I1". Widening the temp makes the statement itself invalid, and no other
encoding of a store-conditional exists.
guest_arm64_toIR.cbuilds the same sequence withIty_I1andIop_1Uto64, which is what this restores.feq.s/flt.s/feq.d/flt.d. TheirIop_CmpEQ32yieldsIty_I1into anIty_I32temp. The
flecase in the sameswitchalready wraps its comparisons inIop_1Uto32; feqand flt now do the same.
Before, on
master:with
vex: the 'impossible' happened: sanityCheckFail: exiting due to bad IRandERROR = Ist.LLSC(SC).result: not :: Ity_I1on stderr. After, all six decode.The visible cost is in angr: a RISC-V block that runs into one of these becomes undecodable
bytes, and
CFGFast's linear scan then restarts two bytes into the four-byte instruction, soblocks begin in the middle of instructions. Over a corpus sweep this accounted for the whole
RISC-V share of that symptom.
Consumed by angr/pyvex#566, which carries the regression tests. Fixes angr/pyvex#516,
whose diagnosis covers
fltonly.Validation: angr/pyvex#566 (comment)