https://bugs.kde.org/show_bug.cgi?id=434296
--- Comment #4 from Andreas Arnez <ar...@linux.ibm.com> --- (In reply to Julian Seward from comment #3) > Is it possible for any incoming instruction to cause this assertion to > fail? Yes. Of course, only invalid code would do that. > If so that should be reported as SIGILL, and not cause an assertion > failure. Right. The s390_insn_assert macro does not behave like vassert(), though. If its argument is false, it reports a "specification exception" up through the call chain. The user would see something like this: vex s390->IR: specification exception: E712 30F0 F082 ==2699373== valgrind: Unrecognised instruction at address 0x1000518. ... ==2699373== ==2699373== Process terminating with default action of signal 4 (SIGILL): dumping core ... I think it's an improvement over the previous logic, which simply called vassert(). Although in practice, I haven't heard about that causing trouble, either. So my take is, whenever I touch an existing IR translator function that uses vassert() for indicating a specification exception, I replace that by s390_insn_assert() instead. > [...] > The one thing I would suggest is that, for the instructions in question, in > the front end, set the returned DisResult::hint field to Dis_HintVerbose. Ah, good point, will do. Is there a recommended threshold when to set this flag? -- You are receiving this mail because: You are watching all bug changes.
