cmd/link, cmd/dist: wrong loader/interpreter used with cross-compiled toolchain for ppc64le

[laboger]

What version of Go are you using (go version)?

$ go version
go version devel go1.19-4484c30f78 Wed

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
ppc64le

What did you do?

Built a cross toolchain on x86 host targeting ppc64le. By default CGO_ENABLED=0 for cross builds.
Moved the toolchain to a ppc64le machine. Many tests work fine except those that use -buildmode=pie. In those cases the test fails.

What did you expect to see?

Tests using -buildmode=pie work.

What did you see instead?

$ go build -buildmode=pie hello.go
$ ./hello
bash: ./hello: No such file or directory
$ file hello
hello: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, with debug_info, not stripped

Same result if I set GO_LDSO=/libd64/ld64.so.2 before the go build command above.

If I set GO_LDSO=/lib64/ld64.so.2 when building the cross toolchain then it uses the correct path to the loader.

Also, if I build a cross compiled toolchain with a cross gcc on the build machine and set CGO_ENABLED=1, then the go binary is built dynamic but is unusable for the same reason.. With CGO_ENABLED=0, the go binary is static so doesn't have that problem.

[cherrymui]

Built a cross toolchain on x86 host targeting ppc64le. By default CGO_ENABLED=0 for cross builds.
Moved the toolchain to a ppc64le machine.

Could you show the commands you run for building and copying the toolchain? Is it just GOARCH=ppc64le ./make.bash then copying using scp or something? Or it is something else?

[laboger]

I did GOOS=linux GOARCH=ppc64le ./make.bash on the x86 host.
I tarred it up and moved it over to my ppc64le machine, then untarred it.
After that I moved the go and gofmt binaries from go/bin/linux_ppc64le/ to go/bin so they were in the normal location.

[cherrymui]

Thanks. During make.bash, cmd/dist writes defaultGO_LDSO in internal/buildcfg/zbootstrap.go ( https://cs.opensource.google/go/go/+/master:src/cmd/dist/buildruntime.go;l=69 ). And the linker picks up that value as the default dynamic linker path.

The linker already does not use defaultGO_LDSO when cross compiling at link time ( https://cs.opensource.google/go/go/+/master:src/cmd/link/internal/ld/elf.go;l=1771 ). But in this case the toolchain is cross-compiled but at link time the host and target are the same so it is not cross compiling (and there is no way for the linker to know it). So it still uses defaultGO_LDSO.

cmd/dist also writes in internal/buildcfg/zbootstrap.go defaultGOOS and defaultGOARCH. But they are just runtime.GOOS and runtime.GOARCH, i.e. the current host, so it doesn't help. Maybe cmd/dist could write a per-platform defaultGO_LDSO, so the linker can choose to use it only when targeting that platform.

cc @ianlancetaylor

[cherrymui]

This doesn't need to target Go 1.19. I think it needs more work to ship a cross-compiled binary release, and we're probably not going to do it for Go 1.19.

[laboger]

On a related note, I noticed this line in cmd/link/internal/ppc64/obj.go:

                Linuxdynld: "/lib64/ld64.so.1",

This is wrong for ppc64le, which is what the default should be since linux/ppc64 doesn't generate pie or dynamic binaries. It didn't seem worthy of its own issue since it has always been this way so this field must never be used, but it should still contain the correct string. It could be fixed along with the fix for this issue in Go 1.20. Probably when using the external linker the interpreter is set in a different way, and that's the way pies were generated up until @pmur s recent changes to the internal linker.

[cherrymui]

@laboger thanks. Yes, this should be fixed. Feel free to send a CL. What should it be?

This string is still used in some cases, for example, when cross compiling (not with a cross-compiled toolchain, but like GOARCH=ppc64le go build -buildmode=pie hello.go on a different architecture), or when GO_LDSO is not set.

[cherrymui]

The C cross toolchain on my machine uses /lib64/ld64.so.2. Maybe this is the correct value?

[laboger]

The C cross toolchain on my machine uses /lib64/ld64.so.2. Maybe this is the correct value?

Yes, it should be 2 since ppc64le is ELF v2. I can create a CL.