In https://golang.org/cl/278473 I corrected $GOROOT/test/fixedbugs/issue11656.go to actually test what it was trying to test: executing a trap instruction at a PC value larger than zero. That fix caused the test to fail on:
Trust: Ian Lance Taylor <firstname.lastname@example.org>
Run-TryBot: Ian Lance Taylor <email@example.com>
Run-TryBot: Emmanuel Odeke <firstname.lastname@example.org>
Reviewed-by: Emmanuel Odeke <email@example.com>
I think what happens is that on machines that the test passes, it faults with SIGSEGV (or maybe SIGBUS) at the CALL instruction when it is jumping to fn, because that address is not executable. On machines that this fails, it actually jumped to fn and executed the trap instruction (somehow the kernel allowed to execute that address), and faulted with SIGTRAP, where it failed to unwind, because the PC doesn't match any function.
It might be possible to do something for better traceback, for example, if the PC is not in any known function, maybe use the LR? Assume the frame size is 0 and hope for the best? Not sure...
Why does this apply to ppc64 but not ppc64le?
Perhaps the kernel on the AIX builder allows execution on that address whereas the Linux/PPC64LE builder doesn't.
I think the test only needs to be disabled on aix-ppc64, but it is disabled for aix-ppc64 and linux-ppc64. The failure log posted above is from aix-ppc64. Not a big deal, I just didn't understand why linux-ppc64 and linux-ppc64le would behave differently for this case.