Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/link: ppc64le internal linking does not handle TOC correctly #15409
The tests in misc/cgo/test fail with -linkmode=internal on ppc64le. From https://build.golang.org/log/a5a334010e62ae540ec0ec4916a8615cae0472d7:
I believe that the problem is this: the PPC ELF v2 ABI requires that every function start with a small prologue that computes the TOC pointer in r2 from the function address in r12. This computation is two instructions; in normal PPC assembler it looks like this:
The problem is that cmd/link is using a different value for
CL 22372 changed ppc64le to use normal cgo initialization on ppc64le. Doing this uncovered a cmd/link error using internal linking. Opened issue 15409 for the problem. This CL disables the test. Update #15409. Change-Id: Ia1bb6b874c1b5a4df1a0436c8841c145142c30f7 Reviewed-on: https://go-review.googlesource.com/22379 Run-TryBot: Ian Lance Taylor <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.org>
FWIW I think if we fix this we could always generate ELFv2-style PIC for
CL https://golang.org/cl/22379 mentions this issue.
Actually, according the the ABI it is not invalid to have multiple TOCs in a module:
I think this is what the code is trying to do. It doesn't handle .sdata or .sbss sections at all, but I get the impression they are not present with default compiler options?
I guess this is where things are going wrong. I don't entirely get how we end up with calls between functions using different TOC pointer values though.
It still seems likely to me that moving to a model with a single TOC would make life easier overall.