runtime: ensure abort actually crashes the process

On all non-x86 arches, runtime.abort simply reads from nil.
Unfortunately, if this happens on a user stack, the signal handler
will dutifully turn this into a panicmem, which lets user defers run
and which user code can even recover from.

To fix this, add an explicit check to the signal handler that turns
faults in abort into hard crashes directly in the signal handler. This
has the added benefit of giving a register dump at the abort point.

Change-Id: If26a7f13790745ee3867db7f53b72d8281176d70
Reviewed-on: https://go-review.googlesource.com/93661
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

1 files changed, 7 insertions, 0 deletions

diff --git a/src/runtime/stubs.go b/src/runtime/stubs.go
index 6019005fbe..7818fd3683 100644
--- a/src/runtime/stubs.go
+++ b/src/runtime/stubs.go
@@ -313,3 +313,10 @@ func bool2int(x bool) int {
 	// exactly what you would want it to.
 	return int(uint8(*(*uint8)(unsafe.Pointer(&x))))
 }
+
+// abort crashes the runtime in situations where even throw might not
+// work. In general it should do something a debugger will recognize
+// (e.g., an INT3 on x86). A crash in abort is recognized by the
+// signal handler, which will attempt to tear down the runtime
+// immediately.
+func abort()