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.
As part of a research project testing the accuracy of the sleigh specifications compared to real hardware, we observed an unexpected behaviour in the single precision float instructions for RISCV. According to Section 12.2, when multiple floating-point precisions are supported the narrower value must be NaN-boxed by setting all upper bits to 1's. When an incorrectly NaN-boxed value is read the input is treated as NaN. The current behaviour ignores the upper bits and zero extends single precision floats. While this pull request does not cover them this is also an issue for half and double precision floats.
It was also found that the
fcvt.s.d
instruction did not use thefassignS
macro and instead wrote directly tofrd
.Correctly handling this cases does bloat disassembly. The or'ing of the value to
0xffffffff00000000
on lines 4 and 7 of "Decompilation with fix" are from theflw
instructions as they are NaN-boxed after being read off the stack. The rest of the logic on lines 4-9 is from thefadd.s
instruction checking if its inputs are NaN-boxed. The or'ing on line 11 is from thefadd.s
instruction NaN-boxing its output. The rest of the logic on lines 11-13 is from thefmv.x.w
instruction checking if its input is correctly NaN-boxed (both decompilations includes the patch #6492).Compiler generated assembly
Decompilation without fix
Decompilation with fix
It should be possible to include most of the functionality of this fix while also generating cleaner decompilation by changing the condition on lines 91, 98, and 105 to
nan(frXXXX)
instead of bit shifting and comparing. If you set "NaN operations" under the Analysis tab on the "Options for Code Brower" window to "ignore all", this should cut out all of the if statements but Ghidra seems to get confused and generates the following decompilation.As this greatly impacts the readability of the current decompilation without adding too much to analysis it has been left as a draft.