Skip to content

cmd/link: ppc64 (big endian) cgo errors  #13192

Open

Description

@laboger

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.

Activity

  1. laboger commented on Nov 9, 2015

    @laboger
    ContributorAuthor

    I've been doing this on a RHEL7.2 system.

  2. mwhudson commented on Nov 9, 2015

    @mwhudson
    Contributor

    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:

    I've been doing this on a RHEL7.2 system.

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

  3. laboger commented on Nov 9, 2015

    @laboger
    ContributorAuthor

    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

  4. added this to the Go1.6 milestone on Nov 9, 2015
  5. mwhudson commented on Nov 9, 2015

    @mwhudson
    Contributor

    @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).

  6. laboger commented on Nov 9, 2015

    @laboger
    ContributorAuthor

    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.

  7. laboger commented on Nov 9, 2015

    @laboger
    ContributorAuthor

    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.

  8. ianlancetaylor commented on Nov 9, 2015

    @ianlancetaylor
    Contributor

    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.

  9. mwhudson commented on Nov 10, 2015

    @mwhudson
    Contributor

    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.

  10. minux commented on Nov 10, 2015

    @minux
    Member
  11. laboger commented on Nov 10, 2015

    @laboger
    ContributorAuthor

    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.

  12. laboger commented on Nov 11, 2015

    @laboger
    ContributorAuthor

    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.

  13. rsc commented on Dec 5, 2015

    @rsc
    Contributor

    We're not going to get to this for Go 1.6.

  14. added this to the Unplanned milestone on Dec 5, 2015
  15. 45 remaining items

  16. zeldin commented on Apr 17, 2019

    @zeldin

    @zte-majiang Ok, sounds like a plan. Thanks!

  17. zte-majiang commented on Apr 21, 2019

    @zte-majiang
    Contributor

    @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

  18. zeldin commented on Apr 22, 2019

    @zeldin

    @zte-majiang Thanks! With this patch applied to 1.12.1, docker builds fine without any interventions necessary. 💯

  19. ianlancetaylor commented on Apr 22, 2019

    @ianlancetaylor
    Contributor

    @zte-majiang Do you want to try to update your changes for master and send a pull request? Thanks.

  20. zte-majiang commented on Apr 23, 2019

    @zte-majiang
    Contributor

    @zeldin Glad to hear the good news! Thanks.
    @ianlancetaylor Yes, I will try to push the fix to trunk. Thanks for inviting.

  21. gopherbot commented on Apr 29, 2019

    @gopherbot
    Contributor

    Change https://golang.org/cl/174317 mentions this issue: cmd/link, runtime: reserve 48 bytes in stack frame for ppc64

  22. mirzak commented on Nov 2, 2020

    @mirzak

    I have some interesting in using cgo on ppc64 and 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:

    dockerd[140]: illegal instruction (4) at 10049504 nip 10049504 lr 1006c7bc code 1 in dockerd[10000000+29ce000]
    dockerd[140]: code: 7c230840 41800010 7ca802a6 480235a1 4bffffec 7fe802a6 fbe1ff91 90010060
    dockerd[140]: code: 3fe011d8 c03f0708 d0210058 d0210050 <f0210cd0> d8210068 90010048 3fe011d8
    

    So either new things have been introducerad in go that need changes or I am doing something wrong.

  23. laboger commented on Nov 2, 2020

    @laboger
    ContributorAuthor

    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?

  24. mirzak commented on Nov 2, 2020

    @mirzak

    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?

    # cat /proc/cpuinfo
    processor	: 0
    cpu		: e5500
    clock		: 400.000000MHz
    revision	: 2.0 (pvr 8024 0020)
    
    timebase	: 400000000
    platform	: QEMU e500
    model		: QEMU ppce500
    

    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)

  25. laboger commented on Nov 2, 2020

    @laboger
    ContributorAuthor

    Correct e5500 is not supported. power8 is the minimum.

  26. zeldin commented on Nov 2, 2020

    @zeldin

    @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?

  27. zte-majiang commented on Dec 31, 2020

    @zte-majiang
    Contributor

    @mirzak Sorry for the delay. As far as I know, there are no new plans to support ppc64 cgo.

  28. added
    cgoIssues affecting runtime/cgo and cmd/go
    on Sep 10, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    cgoIssues affecting runtime/cgo and cmd/gocompiler/runtimeIssues related to the Go compiler and/or runtime.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions