resolve RIP in some x86 fp semantics#1637
Open
Angs12 wants to merge 2 commits into
Open
Conversation
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
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.
Bug
During lifting some fp x86 instructions to BIL the RIP is not resolved:
Fix
This pr adds the reg# function already in x86-64.lisp that resolves the PC to the bitwise-rrm macro
The reg# function hardcodes the value 8 for the instruction length, but x86 instructions have variable lenght,
so i added a primus lisp primitive that uses provides the instruction length in bytes that is already in Knowledge Base
and substituted the hardcoded values with that primitive
After fix