cmd/link: ppc64 (big endian) cgo errors #13192
Comments
|
I've been doing this on a RHEL7.2 system. |
|
Those errors suggest that you're not actually linking externally. Try I'm pretty sure that things still won't work though. On 10 November 2015 at 09:25, laboger notifications@github.com wrote:
|
|
These errors happen during the build of golang on ppc64 if I build with CGO_ENABLED=1. Under ##### Building packages and commands for linux/ppc64. cmd/trace/home/boger/golang/gitsrc/latest/go/pkg/linux_ppc64/net.a(_all.o): unknown relocation type 51; compiled without -fpic? |
|
@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. |
|
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. |
|
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. |
|
Here are the CLs that I am aware of related to ppc64 BE linking which match the patches I had previously used from Minux: 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. |
|
We're not going to get to this for Go 1.6. |
|
This bug is assigned to me but I'm not in a position to work on it. Can someone unassign me? (I don't think I have permissions to do that!) |
|
Unassigned. |
|
Can I get information on what is left to be done to get this to work? On 12/04/2015 11:55 PM, Russ Cox wrote:
|
|
@laboger, my understanding is that the patches Minux posted a while back do work (I think you've said that), but they no longer apply cleanly, and Minux has not had time to update them to the latest Go tree. (Minux is a volunteer; his day job is being a grad student.) If you or anyone else would like to take over those patches, get them to apply to the tree, and send them in for review, we can get them in for Go 1.6. More generally, my understanding was that ppc64 (big-endian) was not as important as ppc64le, and that ppc64le support is committed and working. If that's wrong please let me know. Thanks. |
|
I don't know if ppc64 is less important than ppc64le in general, but certainly to me (and Canonical) it is, as there is no Ubuntu port to ppc64 (and I don't have access to ppc64 hw, so even if I wanted to work on it, in practice I can't). I don't think there is an enormous amount to be done. |
|
Yes your understanding is true -- ppc64 for big endian is not as This question is mainly for my understanding, in case the importance of On 12/07/2015 10:48 AM, Russ Cox wrote:
On 12/04/2015 11:55 PM, Russ Cox wrote:
|
|
I believe that I've found a way to cross compiler binaries for ppc64be. I'm lookking forward to some feedback. regards |
|
@laboger I've got to the same point as you have (followed Ian's instructions and now the build can't find .TOC. entries) and it looks like the ELF v2 ABI isn't implemented on ppc64be in any of the gcc versions I've tried (4.4, 4.8, 5) , which is why we don't see .TOC. entries being created. This can verified by running strings on a generated .o file created using gcc on big- and little-endian and comparing the output. I've tried specifying -mabi=elfv2 on the gcc command line to force it on big-endian, but it's unable to find gnu/stubs-64-v2.h and the compile fails. I've also tried to hack the cgo code to use .toc (lower case), but that's not worked either. Looks like a rebuild of gcc with ABI v2 might be needed to get things going, or cross-compiling as @aleek has done. |
|
ppc64 BE uses ABI v1 and ppc64 LE uses ABI v2. You can't build gcc on a ppc64 BE machine with ABI v2, because everything else on a ppc64 BE machine expects ABI v1 (dynamic linker, assembler, shared libraries, etc.) The golang for ppc64 BE must generate the linking environment that is consistent with ABI v1 for it to link correctly and run there. I did some further investigation on this back when I opened the issue which I didn't add to this issue. There is a lot missing in golang for GOARCH=ppc64 with respect to external linking on ABI v1. The call stubs are not correct, the PLT is not set up correctly, plus probably some other things, in addition to the defining of the .TOC. symbol. @tdolby |
|
@laboger How much work If we're enable golang with cgo on ppc64 BE ? I'm curious about it because we're interesting about docker on Power7 Machine that we purchased before. Thanks. |
We should be able to build docker after this get applied. Updates golang#13192
We should be able to build docker after this get applied. Updates #13192 Change-Id: I5378d3518fac52d6bd4c97828884c1b382b7ace5 GitHub-Last-Rev: 210b7bc GitHub-Pull-Request: #28546 Reviewed-on: https://go-review.googlesource.com/c/146898 Reviewed-by: Jiang Ma <ma.jiang@zte.com.cn> Reviewed-by: Clément Chigot <clement.chigot@atos.net> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
We should be able to build docker after this get applied. Updates #13192 Change-Id: I5378d3518fac52d6bd4c97828884c1b382b7ace5 GitHub-Last-Rev: 210b7bc GitHub-Pull-Request: #28546 Reviewed-on: https://go-review.googlesource.com/c/146898 Reviewed-by: Jiang Ma <ma.jiang@zte.com.cn> Reviewed-by: Clément Chigot <clement.chigot@atos.net> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
|
@zte-majiang congrats on your patch landing in go 1.12.
Have you tried any Docker versions later than 17.03.2? Do they build for you? Thanks. |
|
|
Yes, I tried the golang 1.12 and 1.12.1 releases, via Gentoo ebuilds (and applying a small patch to enable external linking).
The error happens with both 18.03.1 and 18.09.3. There is no current ebuild for 17.03, but I can try a manual build. |
|
Some more information: The crash happens when running |
|
After further investigation, I found that the crash is triggered by the following line in the ebuild: It's not adding the include path that's the issue, but rather the overriding of the default CGO_CFLAGS, which is So I reverse my previous statement -- the crash does seem cgo related, but specific to unoptimized cgo. |
|
@zeldin , I can not reproduce this bug via a simple cgo program. Could you send your "gen-manpages" (and related shared libs) binary to me ? |
|
@zte-majiang I also can't reproduce with a trivial program. Maybe it needs to be complex enough that the garbage collector needs to run? I dunno... |
@zeldin I believe that I have reproduced the bug using a simple hello. It seemed much more complex than I thought. |
|
@zeldin ， I have made a dirty fix against trunk. See attached file. |
|
@zte-majiang Awesome! 🎈 I'll try it out later and let you know the result. |
|
@zte-majiang Ok, first I tried applying your patch to go-1.12.1. I do have a fair bit of RAM, but not that much. 😄 Next I tried with go-9999 (a.k.a. current git master). Your patch applied cleanly, but now when I try to build docker I get this: Bizzare. The package can't find itself? Anyway, this happens much earlier than the point where I would get the crash before, so maybe it's not related to cgo at all, but just to some other issue with current git head? |
|
@zeldin Sorry to hear this... |
|
@zte-majiang Ok, sounds like a plan. Thanks! |
|
@zeldin I have rebuild the fix for go1.12.1, see attached file. |
|
@zte-majiang Thanks! With this patch applied to 1.12.1, docker builds fine without any interventions necessary. 💯 |
|
@zte-majiang Do you want to try to update your changes for master and send a pull request? Thanks. |
|
@zeldin Glad to hear the good news! Thanks. |
|
Change https://golang.org/cl/174317 mentions this issue: |
cgo currently doesn't properly support powerpc64 big-endian, as noted in golang/go#13192, and indeed, we have a large number of build failures of Go packages on this architecture. This commit therefore disables Go on PowerPC64 big-endian (PowerPC64 little-endian is fine). Fixes: http://autobuild.buildroot.net/results/a6e9bac0a735f48d0ba0af081aeac4ed9fdfaca7/ (flannel) http://autobuild.buildroot.net/results/230f52bc35f437836c7a76d4b58ef454635ee0d3/ (docker-containerd) http://autobuild.buildroot.net/results/77c31d6e8f5efe3e024e27a160cf5d1d1952719e/ (runc) http://autobuild.buildroot.net/results/a87b07417ea8bd81ffe27e5661b4359ddc0149ab/ (docker-engine) Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
|
I have some interesting in using cgo on @zeldin , do you have something that works on more recent releases? I tried forward porting #31738 to So either new things have been introducerad in go that need changes or I am doing something wrong. |
|
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? |
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) |
|
Correct e5500 is not supported. power8 is the minimum. |
|
@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. |
|
@mirzak Sorry for the delay. As far as I know, there are no new plans to support ppc64 cgo. |
gopherbot
added
the
compiler/runtime
and others
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.
The text was updated successfully, but these errors were encountered: