cmd/link: add support for c-shared, plugin buildmodes on ppc64le #20756
Labels
Comments
|
I found the problem with c-shared. The code in runtime/rt0_linux_ppc64le.s for _rt0_ppc64le_linux_lib is incorrect because it computes the callee's r2 at the beginning of the function and then saves it onto the caller's stack. This shouldn't be done because the caller should be saving and restoring its own r2 before and after the call. Once this is corrected then c-shared works for ppc64le and can be enabled. |
|
Change https://golang.org/cl/53890 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Aug 9, 2017
This change enables buildmode c-shared on ppc64le. A bug was fixed in runtime/rt0_linux_ppc64le.s that was necessary to make this work. In _rt0_ppc64le_linux_lib, there is code to store the value of r2 onto the caller's stack. However, if this file is compiled using a build mode that maintains the TOC address in r2, then instructions will be inserted at the beginning of this function to generate the r2 value for the callee, not the caller. That means the r2 value for the callee is stored onto the caller's stack. If caller and callee don't have the same r2 values, then the caller will restore the wrong r2 value after it returns. This situation can happen when using dlopen since the caller of this function will be in ld64.so and will definitely have a different TOC. Updates #20756 Change-Id: I6e165e0d0716e73721bbbcc520e8302e4856e3ba Reviewed-on: https://go-review.googlesource.com/53890 Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
Change https://golang.org/cl/55850 mentions this issue: |
|
Change https://golang.org/cl/62890 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Sep 11, 2017
On ppc64le, functions compiled with -shared expect r12 to hold the function's address for indirect calls. Previously this was enforced by generating a move instruction if the address wasn't already in r12. This change avoids that extra move by requesting r12 in the CALL ops that do indirect calls. As a result of adding support for plugins on ppc64le, it was discovered that there would be more cases where this extra move was needed, so this seemed like a better solution. Updates #20756 Change-Id: I6770885a46990f78c6d2902a715dcdaa822192a1 Reviewed-on: https://go-review.googlesource.com/62890 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com>
laboger
added a commit
to powertechpreview/go
that referenced
this issue
Feb 2, 2018
This enables -buildmode=c-shared on ppc64le. It is described in golang issue golang#20756
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?This is intended for go 1.10
What operating system and processor architecture are you using (
go env)?ppc64le Ubuntu, RH
These buildmodes are currently not supported on ppc64le. I've been working on plugin, and it seems to work but it needs some clean up.
I tried to enable c-shared but something's missing and I'm not sure what. When I try to run the tests from testcshared, some work but the one that does a dlopen on a cshared library is getting a segv in dl_open_worker.
The text was updated successfully, but these errors were encountered: