You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've built golang from master with the patches from issue 11184 to get external linking to work with ppc64le. That seems to work well on ppc64le with external linking and cgo.
In cmd/dist/build.go, linux/ppc64le is in the cgoEnabled map but linux/ppc64 is not. So the build of golang with the latest patches on ppc64 does not quite work with cgo.
If I build the golang toolchain on ppc64 with CGO_ENABLED=1, I first get this error:
cannot use dynamic imports with -d flag
I made a change to cmd/link/internal/ppc64/obj.go to get rid of this message, but then hit this error:
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
......
runtime/cgo(.opd): unexpected relocation type 307
.......
and then too many errors
I can see that relocation type 51 is R_PPC64_TOC and that is not handled by the code. I tried adding those defines but not sure what should be generated for this relocation type. If there are suggestions on what to do I can try them out.
These errors happen during the build of golang on ppc64 if I build with CGO_ENABLED=1.
They don't happen if CGO_ENABLED is not set.
Under ##### Building packages and commands for linux/ppc64.
.....
cmd/pprof
net/rpc/jsonrpc
cmd/trace
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
runtime/cgo(.opd): unexpected relocation type 307
runtime/cgo(.opd): unexpected relocation type 307
/home/boger/golang/gitsrc/latest/go/pkg/tool/linux_ppc64/link: too many errors
@laboger so you're saying that the patches from issue 11184 break building go on ppc64? that's bad, I'll make sure to fix that. I'm not promising to make external linking work on ppc64 though (which is what I thought this was about).
I'm sorry that I wasn't clear. I'm not saying your patches for 11184 break the build of ppc64. The above errors occur if I build on ppc64 and set CGO_ENABLED=1. The errors are the same or similar if I try to do the same build without your patches on ppc64.
You are correct, the point of this issue is to document the errors that I've seen with external linking on ppc64. I used your patches in my testing just because they are the latest changes I'm aware of for linking on Power. I understand you are not promising to make it work for ppc64, but I'm trying to understand how much is missing from external linking for ppc64.
This issue should not affect the merging of your patches from 11184. They work great and I know of no problem with them. They are for ppc64le, this issue is ppc64.
Just to make sure we're all on the same page, these errors are from internal linking, which is what the toolchain does when building the tools. Presumably something has changed causing the C compiler to generate R_PPC64_TOC relocs. The code in cmd/link/internal/ppc64/asm.go needs to handle R_POWER_TOC, by resolving it to the value of symtoc. The code in cmd/link/internal/ld/ldelf.go needs to recognize R_PPC64_TOC, setting the size to 8.
I don't think cgo works on BE (I have an old patch set to enable
external linking, but it needs major updating after Michael's changes.)
Austin's internal linking work is for ppc64le.
What's the version of gcc?
I have some old patches that Minux gave me back on May to make external linking work. There are only a few ppc64 BE specific changes that aren't in Michael's. I will try adding them and see if that helps. Perhaps something in his patches prevents the generation of R_PPC64_TOC.
My RHEL 7.2 ppc64 BE machine defaults to gcc 4.8.5.
The file asm.go from 9677 and 9673 is a question because I see there are conflicting changes now with what's upstream.
I tried to add support to handle R_PPC64_TOC based on Ian's comments above but was unsure what to put in adddynrel for the R_PPC64_TOC case.
And then after making those changes, I see errors like this:
TOC-relative relocation in object without .TOC.
I don't see where a .TOC. object would get generated so it would be found when calling Linkrlookup.
I'm not sure what the next step is to make this work. I agree with previous comments that when CGO_ENABLED=1 on ppc64 BE this has probably never worked. I can see that gcc generates .opd sections with the R_PPC64_TOC relocation type and that happens even with older versions of gcc. I found this .opd section in some of the _all.o files that are generated during the golang build that are generating the error message about the missing relocation type.
Usually an illegal instruction means your hardware does not support the minimum instruction set used by Golang. If you look in /proc/cpuinfo, what is the cpu?
Usually an illegal instruction means your hardware does not support the minimum instruction set used by Golang. If you look in /proc/cpuinfo, what is the cpu?
If I understand the state of things, e5500 is not supported? So this really unrelated to the original issue. I tried compiling a simple hello-world (without CGO) application and got same error (illegal instruction)
@mirzak The latest version I have working is 1.13.15. As laboger says though, you're unlikely to get any recent version running on Power ISA v.2.06.
Might I suggest gccgo, which has a more mature and capable code generation backend?
Activity
laboger commentedon Nov 9, 2015
I've been doing this on a RHEL7.2 system.
mwhudson commentedon Nov 9, 2015
Those errors suggest that you're not actually linking externally. Try
adding -ldflags=-linkmode=external to your go tool invocation.
I'm pretty sure that things still won't work though.
On 10 November 2015 at 09:25, laboger notifications@github.com wrote:
laboger commentedon Nov 9, 2015
These errors happen during the build of golang on ppc64 if I build with CGO_ENABLED=1.
They don't happen if CGO_ENABLED is not set.
Under ##### Building packages and commands for linux/ppc64.
.....
cmd/pprof
net/rpc/jsonrpc
cmd/trace
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/runtime/cgo.a(_all.o): unknown relocation type 51; compiled without -fpic?
runtime/cgo(.opd): unexpected relocation type 307
runtime/cgo(.opd): unexpected relocation type 307
/home/boger/golang/gitsrc/latest/go/pkg/tool/linux_ppc64/link: too many errors
mwhudson commentedon Nov 9, 2015
@laboger so you're saying that the patches from issue 11184 break building go on ppc64? that's bad, I'll make sure to fix that. I'm not promising to make external linking work on ppc64 though (which is what I thought this was about).
laboger commentedon Nov 9, 2015
I'm sorry that I wasn't clear. I'm not saying your patches for 11184 break the build of ppc64. The above errors occur if I build on ppc64 and set CGO_ENABLED=1. The errors are the same or similar if I try to do the same build without your patches on ppc64.
You are correct, the point of this issue is to document the errors that I've seen with external linking on ppc64. I used your patches in my testing just because they are the latest changes I'm aware of for linking on Power. I understand you are not promising to make it work for ppc64, but I'm trying to understand how much is missing from external linking for ppc64.
laboger commentedon Nov 9, 2015
This issue should not affect the merging of your patches from 11184. They work great and I know of no problem with them. They are for ppc64le, this issue is ppc64.
ianlancetaylor commentedon Nov 9, 2015
Just to make sure we're all on the same page, these errors are from internal linking, which is what the toolchain does when building the tools. Presumably something has changed causing the C compiler to generate R_PPC64_TOC relocs. The code in cmd/link/internal/ppc64/asm.go needs to handle R_POWER_TOC, by resolving it to the value of symtoc. The code in cmd/link/internal/ld/ldelf.go needs to recognize R_PPC64_TOC, setting the size to 8.
mwhudson commentedon Nov 10, 2015
FWIW, I'm not sure that cgo has ever worked on ppc64 BE (ping @aclements @minux), so it might not be C compiler changes to blame.
minux commentedon Nov 10, 2015
laboger commentedon Nov 10, 2015
I have some old patches that Minux gave me back on May to make external linking work. There are only a few ppc64 BE specific changes that aren't in Michael's. I will try adding them and see if that helps. Perhaps something in his patches prevents the generation of R_PPC64_TOC.
My RHEL 7.2 ppc64 BE machine defaults to gcc 4.8.5.
laboger commentedon Nov 11, 2015
Here are the CLs that I am aware of related to ppc64 BE linking which match the patches I had previously used from Minux:
https://go-review.googlesource.com/#/c/9677
change to obj.go no longer needed due to MHDs change
https://go-review.googlesource.com/#/c/9676
change to tls_ppc64x.s no longer needed due to MHDs change in TLS handling
I applied the other changes from this CL.
https://go-review.googlesource.com/#/c/9673
change to obj.go no longer needed
The file asm.go from 9677 and 9673 is a question because I see there are conflicting changes now with what's upstream.
I tried to add support to handle R_PPC64_TOC based on Ian's comments above but was unsure what to put in adddynrel for the R_PPC64_TOC case.
And then after making those changes, I see errors like this:
TOC-relative relocation in object without .TOC.
I don't see where a .TOC. object would get generated so it would be found when calling Linkrlookup.
I'm not sure what the next step is to make this work. I agree with previous comments that when CGO_ENABLED=1 on ppc64 BE this has probably never worked. I can see that gcc generates .opd sections with the R_PPC64_TOC relocation type and that happens even with older versions of gcc. I found this .opd section in some of the _all.o files that are generated during the golang build that are generating the error message about the missing relocation type.
rsc commentedon Dec 5, 2015
We're not going to get to this for Go 1.6.
45 remaining items
zeldin commentedon Apr 17, 2019
@zte-majiang Ok, sounds like a plan. Thanks!
zte-majiang commentedon Apr 21, 2019
@zeldin I have rebuild the fix for go1.12.1, see attached file.
Please try it and let me know whether it's ok for you, thanks.
goppc64-112.zip
zeldin commentedon Apr 22, 2019
@zte-majiang Thanks! With this patch applied to 1.12.1, docker builds fine without any interventions necessary. 💯
ianlancetaylor commentedon Apr 22, 2019
@zte-majiang Do you want to try to update your changes for master and send a pull request? Thanks.
zte-majiang commentedon Apr 23, 2019
@zeldin Glad to hear the good news! Thanks.
@ianlancetaylor Yes, I will try to push the fix to trunk. Thanks for inviting.
gopherbot commentedon Apr 29, 2019
Change https://golang.org/cl/174317 mentions this issue:
cmd/link, runtime: reserve 48 bytes in stack frame for ppc64go: remove powerpc64 big-endian from supported architectures
mirzak commentedon Nov 2, 2020
I have some interesting in using cgo on
ppc64and I am curious on the status of this or any further plans? @zte-majiang@zeldin , do you have something that works on more recent releases?
I tried forward porting #31738 to
go1.15.3, but I get illegal instruction errors during runtime, e.g docker:So either new things have been introducerad in go that need changes or I am doing something wrong.
laboger commentedon Nov 2, 2020
Usually an illegal instruction means your hardware does not support the minimum instruction set used by Golang. If you look in /proc/cpuinfo, what is the cpu?
mirzak commentedon Nov 2, 2020
I believe you are correct @laboger.
If I understand the state of things, e5500 is not supported? So this really unrelated to the original issue. I tried compiling a simple hello-world (without CGO) application and got same error (illegal instruction)
laboger commentedon Nov 2, 2020
Correct e5500 is not supported. power8 is the minimum.
zeldin commentedon Nov 2, 2020
@mirzak The latest version I have working is 1.13.15. As laboger says though, you're unlikely to get any recent version running on Power ISA v.2.06.
Might I suggest gccgo, which has a more mature and capable code generation backend?
zte-majiang commentedon Dec 31, 2020
@mirzak Sorry for the delay. As far as I know, there are no new plans to support ppc64 cgo.