On 21.05.21 13:19, Ilya Leoshkevich wrote:
Verify that s390x-specific uc_mcontext.psw.addr is reported correctly.

Signed-off-by: Ilya Leoshkevich <i...@linux.ibm.com>
---
  tests/tcg/s390x/Makefile.target |  1 +
  tests/tcg/s390x/sigill.c        | 52 +++++++++++++++++++++++++++++++++
  2 files changed, 53 insertions(+)
  create mode 100644 tests/tcg/s390x/sigill.c

diff --git a/tests/tcg/s390x/Makefile.target b/tests/tcg/s390x/Makefile.target
index 241ef28f61..8699d829a5 100644
--- a/tests/tcg/s390x/Makefile.target
+++ b/tests/tcg/s390x/Makefile.target
@@ -8,3 +8,4 @@ TESTS+=exrl-trtr
  TESTS+=pack
  TESTS+=mvo
  TESTS+=mvc
+TESTS+=sigill
diff --git a/tests/tcg/s390x/sigill.c b/tests/tcg/s390x/sigill.c
new file mode 100644
index 0000000000..aab560b30f
--- /dev/null
+++ b/tests/tcg/s390x/sigill.c
@@ -0,0 +1,52 @@
+#include <assert.h>
+#include <signal.h>
+#include <string.h>
+#include <ucontext.h>
+#include <unistd.h>
+
+/*
+ * The labels for the instruction that generates a SIGILL and for the one that
+ * follows it. They could have been defined in a separate .s file, but this
+ * would complicate the build, so use the inline asm instead.
+ */
+
+void expected_si_addr(void);
+void expected_psw_addr(void);
+
+asm(".globl\texpected_si_addr\n"
+    "expected_si_addr:\t.byte\t0x00,0x00\n"
+    "\t.globl\texpected_psw_addr\n"
+    "expected_psw_addr:\tbr\t%r14");
+
+static void handle_signal(int sig, siginfo_t *info, void *ucontext)
+{
+    if (sig != SIGILL) {
+        _exit(1);
+    }
+
+    if (info->si_addr != expected_si_addr) {
+        _exit(2);
+    }
+
+    if (((ucontext_t *)ucontext)->uc_mcontext.psw.addr !=
+            (unsigned long)expected_psw_addr) {
+        _exit(3);
+    }
+}
+
+int main(void)
+{
+    struct sigaction act;
+    int ret;
+
+    memset(&act, 0, sizeof(act));
+    act.sa_sigaction = handle_signal;
+    act.sa_flags = SA_SIGINFO;
+
+    ret = sigaction(SIGILL, &act, NULL);
+    assert(ret == 0);
+
+    expected_si_addr();
+
+    return 0;
+}


That makes it much clearer, thanks.

Reviewed-by: David Hildenbrand <da...@redhat.com>

--
Thanks,

David / dhildenb


Reply via email to