Hi found this issue through 
* Build log: https://buildd.debian.org/status/fetch.php?pkg=siso&arch=ppc64el&ver=1.6.4%2Bds-1&stamp=1792241113&file=log


I did some tests, and found that Go programs built for ppc64el with -buildmode=pie die at startup with
golang-1.27. The same source built without -buildmode=pie runs fine, and
golang-1.26 was fine, so this is a 1.27 regression. It makes siso FTBFS on
ppc64el, because debian/rules runs the binary it just built to generate the
man page.

Smallest case I found:

   package main

   import (
       "fmt"
       "os"

       "golang.org/x/sys/unix"
   )

   func main() {
       _, _ = unix.IoctlGetTermios(int(os.Stdout.Fd()), unix.TCGETS)
       fmt.Println("ok")
   }

   GOARCH=ppc64le CGO_ENABLED=0 go build -buildmode=pie -o r .

Under qemu-ppc64le that binary never returns and sits at 100% CPU. Without
-buildmode=pie it prints ok. SIGQUIT on the wedged process gives a stack the
runtime itself rejects:

   runtime: g 1: unexpected return pc for sync.(*Pool).pinSlow called from 0x1001b8890

siso fails earlier and harder, on the first sampled allocation in a package
init:

   runtime.mProf_Malloc     runtime/mprof.go:443
   runtime.panicBounds      runtime/asm_ppc64x.s:1410
   runtime.findfunc         runtime/symtab.go:923
   runtime.findmoduledatap  runtime/symtab.go:866    <- SIGSEGV
   siso/ui.init.0           ui/ui.go:82

mprof.go:443 is mp.profStack[:debug.profstackdepth+2], and profStack is
allocated as 1+maxSkip+profstackdepth (proc.go:1076), so the bound is 130
against a length of 135: that check cannot legitimately fire. The SIGSEGV
afterwards is at a different address in each build, 0x2a0 then 0x0, which
looks like a garbage pointer rather than a nil one. Both faults are reads of
runtime globals early in startup, and on ppc64 a PIE binary reaches globals
through the TOC in r2.

buildd history is at
https://buildd.debian.org/status/logs.php?pkg=siso&arch=ppc64el : 1.6.4+ds-1
Maybe-Failed three times, while 1.5.13+ds-1 through 1.5.22+ds-2 all succeeded
under golang-1.26. I reproduced it in a clean sid ppc64el chroot under
qemu-user, so it is not hardware specific.


I checked for duplicates today and found none: no ppc64el bug against
golang-1.27, nothing matching in the Go tracker. The
closest precedents are https://github.com/golang/go/issues/30283,
Best,

Juan

Reassigning. This is not golang-1.27.

I filed it against golang-1.27 because siso built on ppc64el under 1.26 and
failed under 1.27. Two things had changed at once. Holding the toolchain fixed
and varying only x/sys, three runs each:

    go1.27.2 + x/sys 0.48.0, -buildmode=pie, ppc64le   ok     3/3
    go1.27.2 + x/sys 0.49.0, -buildmode=pie, ppc64le   crash  3/3
    go1.26.9 + x/sys 0.49.0, -buildmode=pie, ppc64le   crash  3/3

Both toolchains fail with 0.49.0, so only the x/sys version matters.

The cause is in unix/asm_linux_ppc64x.s. The Syscall, Syscall6, RawSyscall and
RawSyscall6 trampolines branch to the global entry point of the generated
syscall ABI0 wrapper without setting R12:

    TEXT ·Syscall(SB),NOSPLIT,$0-56
            MOVD    $syscall·Syscall(SB), R31
            MOVD    R31, CTR
            JMP     (CTR)

In a PIE binary that wrapper derives its TOC from R12, as ELFv2 requires of a
caller that enters through the global entry point. R12 is stale, so the TOC is
displaced and every global access afterwards is wrong. Non-PIE wrappers have no
such prologue, which is why only PIE fails.

One instruction per trampoline fixes it, MOVD R31, R12 after the address load.
The trampolines came back in upstream b6b8557 (2026-10-05), which reverts
7155702 (2018, Fixes golang/go#16662). That commit had removed them on purpose,
because the ppc64x external linker cannot always handle the direct branch when
the offset is too far. Not forwarded upstream yet.

The patch and the measurements are in this merge request:
https://salsa.debian.org/go-team/packages/golang-golang-x-sys/-/merge_requests/6

ppc64 big-endian is not tested. The file serves both and I only ran ppc64le.

Reported upstream as golang/go#82324. The fix is up for review as
https://go-review.googlesource.com/c/sys/+/850585.