For some reason, aix sometimes executes the bogus function body. This
should never happen as it lives in a no-execute section. It might be
a transient permission blip as the heap grows.
Add a small function to cleanup and synchronize the icache before
jumping to the bogus function to ensure it causes a panic, not SIGILL.
Fixes#44583
Change-Id: Iadca62d82bfb70fc62088705dac42a880a1208fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/377314
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 279423 introduced a regression in this test as it incorrectly laid
out various instructions. In the case of arm, the second instruction
was overwriting the first. In the case of 386, amd64 and s390x, the
instructions were being appended to the end of the slice after 64
zero bytes.
This was causing test failures on "linux/s390x on z13".
Fixes#44028
Change-Id: Id136212dabdae27db7e91904b0df6a3a9d2f4af4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In issue11656.go, it tests that if the runtime can get a
reasonable traceback when it faults at a non-function PC. It does
it by jumping to an address that contains an illegal or trap
instruction. When it traps, the SIGTRAP crashes the runtime.
This CL changes it to use an instruction that triggers SIGSEGV.
This is due to two reasons:
- currently, the handling of bad PC is done by preparePanic,
which is only used for a panicking signal (SIGSEGV, SIGBUS,
SIGFPE), not a fatal signal (e.g. SIGTRAP).
- the test uses defer+recover to get a traceback, which only
works for panicking signals, not fatal signals.
Ideally, we should handle all kinds of faults (SIGSEGV, SIGBUS,
SIGILL, SIGTRAP, etc.) with a nice traceback. I'll leave this
for the future.
This CL also adds RISCV64 support.
Fixes#43283.
Change-Id: I5e0fbf8530cc89d16e05c3257d282bc1d4d03405
Reviewed-on: https://go-review.googlesource.com/c/go/+/279423
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #11656
For #43283
Change-Id: I1fcf2b24800f421e36201af43130b487abe605b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/279312
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
The issue11656 code was using the trap instruction as a PC value,
but it is intended to call a PC value that contains the trap instruction.
It doesn't matter too much as in practice the address is not
executable anyhow. But may as well have the code act the way it
is documented to act.
Also, don't run the test with gccgo/GoLLVM, as it can't work.
The illegal instruction will have no unwind data, so the unwinder
won't be able to get past it. In other words, gccgo/GoLLVM suffer
from the exact problem that the issue describes, but it seems insoluble.
For golang/go#11656
Change-Id: Ib2e50ffc91d215fd50e78f742fafe476c92d704e
Reviewed-on: https://go-review.googlesource.com/c/go/+/278473
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The general policy for the current state of js/wasm is that it only
has to support tests that are also supported by nacl.
The test nilptr3.go makes assumptions about which nil checks can be
removed. Since WebAssembly does not signal on reading a null pointer,
all nil checks have to be explicit.
Updates #18892
Change-Id: I06a687860b8d22ae26b1c391499c0f5183e4c485
Reviewed-on: https://go-review.googlesource.com/110096
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
An instruction consisting of all 0s causes an illegal instruction
signal on s390x. Since 0s are the default in this test this CL just
makes it explicit.
Change-Id: Id6e060eed1a588f4b10a4e4861709fcd19b434ac
Reviewed-on: https://go-review.googlesource.com/20962
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Skip fixedbugs/issue10607.go because external linking is not supported
yet.
Skip nilptr3.go because of issue #9058 (same as ppc64).
Change-Id: Ib3dfbd9a03ee4052871cf57c74b3cc5e745e1f80
Reviewed-on: https://go-review.googlesource.com/14461
Reviewed-by: Minux Ma <minux@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
As detailed in #11910, the current implementation attempts to execute an area
of memory with unknown content. If the memory is executable, the result is
unpredictable - instead, make the test deterministic by attempting to execute
an instruction that is known to trigger a trap on the given architecture.
The new implementation is written by iant@ and provided via #11910.
Update issue #11910
Change-Id: Ia698c36e0dd98a9d9d16a701f60f6748c6faf896
Reviewed-on: https://go-review.googlesource.com/15058
Run-TryBot: Joel Sing <jsing@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox fixed this issue for other systems
in CL 12026, but the Plan 9 part was forgotten.
Fixes#11656.
Change-Id: I91c033687987ba43d13ad8f42e3fe4c7a78e6075
Reviewed-on: https://go-review.googlesource.com/12762
Reviewed-by: Russ Cox <rsc@golang.org>
