Description of problem: There has been observe rather significant size grow of go1.17 built binaries in shared mode on ppc64le after binutils-2.37-11.fc36(first affected version). This caused failures in the Go's compiler internal tests suite. Binaries themself look sane and functional, apart from significant size grow, but I haven't poked at them beyond objdump. Version-Release number of selected component (if applicable): binutils-2.37-11.fc36 and later How reproducible: Always Steps to Reproduce: To trigger the golang tests suite failure 1. dnf install golang golang-misc 2. go tool dist test -run testshared To build the attached binaries(that get built during the test suite test and are inspected) 1. dnf install golang golang-src golang-misc golang-shared 2. cd /usr/lib/golang/misc/cgo/testshared/testdata/ 3. go build -o trivial -linkshared ./trivial 4. ls -al ./trivial Actual results: ls -al ./trivial drwxr-xr-x. 2 root root 116 Dec 7 16:00 . drwxr-xr-x. 26 root root 4096 Dec 3 15:08 .. -rwxr-xr-x. 1 root root 211496 Dec 7 14:19 trivial -rw-r--r--. 1 root root 203 Dec 7 11:29 trivial.go Expected results: Something more inline with result with binutils-2.37-10.fc36 ls -al ./trivial drwxr-xr-x. 2 root root 116 Dec 7 16:00 . drwxr-xr-x. 26 root root 4096 Dec 3 15:08 .. -rwxr-xr-x. 1 root root 80424 Dec 7 14:24 trivial -rw-r--r--. 1 root root 203 Dec 7 11:29 trivial.go Additional info: To note this has been reproduced with go 1.17 and master branch. I haven't tested go1.16. But Fedora 35 is not affected, with go1.17 and master.
Created attachment 1845240 [details] trivial built with 2.37-10 and master branch go
Created attachment 1845241 [details] trivial built with 2.37-11 and master branch go
Hi Jakub, (In reply to Jakub Čajka from comment #0) > There has been observe rather significant size grow of go1.17 built binaries > in shared mode on ppc64le after binutils-2.37-11.fc36(first affected > version). Actually the code itself has not grown in size. Rather the linker is now separating code and read-only data into separate segments, aligned to very large boundaries, and this makes the file size appear to grow. > This caused failures in the Go's compiler internal tests suite. That might be worth investigating, since the "large" binaries should be just the same as the normal binaries. Well unless you have read-only data that needs to be executed as code. Assuming that you do not want to change the internal tests, then you can tell the linker to resume its old behaviour via the use of the: -z,noseparate-code command line option. (Or -Wl,-z,noseparate-code if you use gcc). Given that this a GO problem however I am not sure how to pass options on to the linker. I know that you can use "-buildmode pie" to pass "-pie" on. Maybe "-buildmode z,noseparate-code" will work ? Cheers Nick
Thank for the explanation. If I do understand that correctly that means that on 64k pages that could lead up to nearly 128k of grow in general(which seems to be the case here), right? For Go I guess it would be just that it would need to adjust the "fail" threshold based on the system's page size, if I'm not mistaken.
(In reply to Jakub Čajka from comment #5) > For Go I guess it would be just that it would need to adjust the "fail" > threshold based on the system's page size, if I'm not mistaken. No, it's a platform-specific constant. For example, Fedora kernels uses 4K pages on AArch64, but the toolchain still builds executables in such a way that they can run on 64K systems. So you still get the overhead from 64K pages, and the run-time page size does not factor in. I plan to add these constants to a future <sys/pagesize.h> in glibc, but that may not actually help you (only as a reference).
(In reply to Jakub Čajka from comment #5) > For Go I guess it would be just that it would need to adjust the "fail" > threshold based on the system's page size, if I'm not mistaken. In which case would you mind if I changed the Component of this BZ over to GO ?
I have taken it. Thank you, for all the info.
This bug appears to have been reported against 'rawhide' during the Fedora 36 development cycle. Changing version to 36.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 36 entered end-of-life (EOL) status on 2023-05-16. Fedora Linux 36 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.