| Summary: | s390x: handle sigbus and sigsegv from VEX | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Christian Borntraeger <borntraeger> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arnez, flo2030 |
| Priority: | NOR | ||
| Version First Reported In: | 3.7 SVN | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | pass sigbus and sigsegv to the scheduler | ||
We will need to issue SIGSEGV/SIGBUS from some instructions (e.g. crypto for wrong function codes will cause a specification exception that causes Linux to deliver a SIGSEGV). The attached patch prepares the host part of s390x VEX. What's the larger plan? There are many conditions that lead to a specification exception (pp 6-35 POPs). E.g. generated branch address is odd, invalid register is used to denote a register pair (also for FLOGR) and many more Are you suggesting we should check all that? On 17/05/11 23:22, Florian Krohm wrote:
> What's the larger plan? There are many conditions that lead to a specification
> exception (pp 6-35 POPs). E.g. generated branch address is odd, invalid
> register is used to denote a register pair (also for FLOGR) and many more
> Are you suggesting we should check all that?
My idea was to ignore anything that is usually generated by gcc and only do
these checks on special stuff where it seems appropriate.
This patch only wires up some existing infrastructure- currently a no-op.
Christian
(In reply to Christian Borntraeger from comment #1) > We will need to issue SIGSEGV/SIGBUS from some instructions (e.g. crypto for > wrong function codes will cause a specification exception that causes Linux > to deliver a SIGSEGV). That's not quite correct. Instead, specification exceptions lead to SIGILL. For a full overview of how architectural exceptions are translated to Linux signals, see the section "Exception Interface" in the s390x ABI: https://github.com/ibm/s390x-abi In the meantime we added lots of checks in the translator, to yield SIGILL via Ijk_NoDecode in cases where the hardware would generate specification exceptions. See, e.g. the many invocations of s390_insn_assert() in guest_s390_toIR.c. Similarly, the extension handlers in extension-s390x.c yield SIGILL by returning ExtErr_Illop when they recognize inputs that would generate a specification exception. These two mechanisms cover almost all relevant cases where we like to synthesize signals for bad instructions. A few special cases might be missing, particularly those that require run-time checks such as for the "load and add" operand alignment. If the need arises, those should be addressed with separate Bugs. SIGSEGV/SIGBUS, on the other hand, are generated for translation exceptions only. This should not be specific to s390x. With this, I consider this Bug "fixed". |
Created attachment 60083 [details] pass sigbus and sigsegv to the scheduler Version: 3.7 SVN OS: Linux Reproducible: Didn't try