/cc @spetrovic77

Looking at this...

https://go-review.googlesource.com/#/c/8766/1 will fix this test.

Dave, this seems to be a linking problem on PPC64le, please look at the CL description and tell me if you know what's going on.

@aclements

I wish I knew what was going on. I agree linking is involved as there are
other tests in that file which are excluded on ppc64 due to a lack of
external linking.

On Sat, Apr 11, 2015 at 10:35 AM, Srdjan Petrovic notifications@github.com
wrote:

https://go-review.googlesource.com/#/c/8766/1 will fix this test.

Dave, this seems to be a linking problem on PPC64le, please look at the CL
description and tell me if you know what's going on.

—
Reply to this email directly or view it on GitHub
#10410 (comment).

The build failure is fixed, but the question on why the test has failed still remains. Here is the simplest code that demonstrates the failure (before CL 8766).

package main

// void gopanic(void);
//
// static void start(void) {
// gopanic();
// }
import "C"

//export gopanic
func gopanic() {
panic("BOOM")
}

func main() {
C.start()
}

The failure occurs when start() invokes gopanic(), in the _cgo_wait_runtime_init_done() call. If _cgo_wait_runtime_init_done() is non-empty (say, fprintf is added to it), it will fail.

The PPC ELF v2 ABI requires that every function start with a small prologue that computes the TOC pointer in r2 from the function address in r12. This computation is two instructions; in normal PPC assembler it looks like this:

0: addis 2,12,.TOC.-0b@ha
addi 2,2,.TOC.-0b@l

The symbol .TOC. is not defined in an object file, and is magically defined by the linker. The linker must arrange that every function in the same module (shared library or executable) compute the same value for r2.

The problem here is that 9l is using a different value for .TOC. for functions defined in different object files. I haven't sorted it all out, but 9l seems to use a different .TOC. symbol for each object file, and to give them different values. This may be correct for the ELF v1 ABI; I'm not sure. It's not correct for the ELF v2 ABI used on PPC64le.

The different TOC value causes some calls to pthread_mutex_lock to load the wrong value from the GOT and branch to the wrong function, leading to a crash.

I hope somebody else can take it from here.

Ah, I recently found the same cmd/link (nee 9l) behaviour around using a different .TOC. for each object file that Ian refers to and was very confused by it. Glad to hear Ian thinks it's wrong too :-)

External linking will fix this though.

We're not going to make it to Go 1.6 for ppc64 external linking.

Has this problem been fixed by the use of external linking? If we drop runtime/cgo/gcc_libint_linux_ppc64x.c and simply use runtime/cgo/gcc_libint.c on linux-ppc64 and linux-ppc64le, do all the tests pass?

CC @spetrovic77 @laboger

This testcase worked for me on master latest on an Ubuntu system and RHEL 7.2 ppc64le.
The intent of this issue is not ppc64 BE, is it? The title says ppc64 but the first stack trace posted shows ppc64le.

./runtime.test -test.run=TestCgoExternalThreadPanic -test.v
=== RUN TestCgoExternalThreadPanic
--- PASS: TestCgoExternalThreadPanic (1.15s)
PASS

go version devel +1492e7d Fri Apr 22 10:08:05 2016 +0000 linux/ppc64le

I think this issue was ppc64le specific, because it was due to ELF ABI v2. I sent a CL.