https://bugs.kde.org/show_bug.cgi?id=509157
Carl Friedrich Bolz <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Carl Friedrich Bolz <[email protected]> --- We (Christoph and I are collaborating on this) have thought about this a bit more. There is no Valgrind-level reproducer, and probably no real bug in Valgrind. The problem is more lack of documentation/clarity of the precise semantics of the VEX IR shift instructions, which the angr project misinterpreted. Why there is no Valgrind-level reproducer, using RISC-V sra as an example: sra gets translated into VEX IR Sar64(rs1, 64to8(rs2)). Sar64 then gets translated into an sra instruction again. If we execute the untranslated and translated variants with a value of rs2 >= 64, then both the untranslated and the translated form will perform a mask, ignoring all the higher bits. The mask of the translated form is performed in two steps, first masking of the highest 56 bits by the 64to8 instruction, then the sar will mask off two further bits before doing the actual shift. The resulting values in both situations are the same. The real "problem" is a vagueness of the semantics of the VEX shift instruction like Shl64/Shr64/Sar64 (and the other bitwidths too). How should they behave if the shift amount is larger than log2 of the first argument size? Is the shift amount implicitly masked and the upper bits ignored (this is what VEX RISC-V instruction selection does right now)? Or should the result be e.g. 0/-1 in the case of an arithmetic right shift with too large shift amount (this is how angr interprets the semantics)? Maybe the Valgrind project could give some kind of pronouncement/add a comment to the header files clarifying this point. (In my personal opinion Valgrind should probably decide that shifts perform an implicit mask. It's what much of the code seems to assume already anyway. It's my superficial impression that some parts of the Valgrind code might also benefit from clarity here. E.g. ir_opt.h doesn't constant-fold shifts with too large shift amounts, and there's a fixme about shift amounts on ARM for vector x vector shifts.) -- You are receiving this mail because: You are watching all bug changes.
