Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upcmd/link: add support for c-shared, plugin buildmodes on ppc64le #20756
Comments
This comment has been minimized.
This comment has been minimized.
|
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. |
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/53890 mentions this issue: |
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>
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/55850 mentions this issue: |
This comment has been minimized.
This comment has been minimized.
|
Change https://golang.org/cl/62890 mentions this issue: |
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>
This enables -buildmode=c-shared on ppc64le. It is described in golang issue golang#20756
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.