-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/link: test TestPIESize fails for ppc64le added in CL 208897 #36023
Comments
Yeah, I'm looking at it. |
The test starts to fail after I checked in CL https://go-review.googlesource.com/c/go/+/209659, which doesn't seem to be quite related. That CL could make the file size increases or decreases slightly (as it changes some PCDATA), for both exe and pie. What seems weird to me is that the file size of PIE binary increases significantly, but none of the sections' sizes actually increase much. For example, the sizes reported by the
Difference is 65456.
Difference is 4608.
old:
new:
What's interesting is that the file offset of old:
new:
@ianlancetaylor any idea why the file offset changes so much? =========================== Full
new:
|
@laboger on the builder, it has ld 2.31.1 and gcc 8.3.0. When linking PIE, the Go linker passes -pie to gcc, and gcc indeed passes -pie to ld. |
What is happening here has something to do with the relro sections. When using relro, the goal is for the relro part of the writable data segment to end at a page boundary. Then the dynamic linker can load the executable, modify the relro part, and then mark those pages as readonly. The relro sections start with In the first program, the addresses happen to work out with just a small gap between the end of At least, I think that is what is happening. Maybe what we need to do here is measure the gaps between the |
@ianlancetaylor this is an interesting observation (makes sense). Is there a design or "reference" document anywhere that talks more about how relro is implemented? |
@cherrymui I am testing outside of a container. The test starts the fail with the commit where it was added when I build and test on my Ubuntu 16.04 system. Based on Ian's last comment, it seems to be somewhat random depending on section offsets and sizes. |
Thanks @ianlancetaylor ! This makes sense. I guess this only shows up on PPC64 because it has a large page size. |
@thanm Do you want a design doc or an explanation? The design doc, such as it is, is https://www.sourceware.org/ml/binutils/2004-01/msg00070.html. My explanation is https://www.airs.com/blog/archives/189. |
Change https://golang.org/cl/210180 mentions this issue: |
Change https://golang.org/cl/220654 mentions this issue: |
In CL 210180 we detect gaps between PT_LOAD segments and subtract them from size calculation. The code there only works when PT_LOAD segments are next to each other. But it is possible that there are other segments in between (e.g. a GNU_RELRO segment). Relax the gap detection to count gaps between PT_LOAD segments regardless of whether they are next to each other. Updates #36023. Updates #35545. Change-Id: I8b94506359fa649a4478acc742d86d4b16022dbc Reviewed-on: https://go-review.googlesource.com/c/go/+/220654 Run-TryBot: Cherry Zhang <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Than McIntosh <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>
cmd/link test TestPIESize fails on tip on the ppc64le builders, both power8 and power9.
On some systems, it fails consistently after this test was added. On some systems, which have newer distros it passes. On the dashboard, it didn't start failing until a few commits after that test was added, not sure why.
When it works for me, ld is >= 2.31. It works for me on a Debian Buster machine with gcc 8.3.0 and ld 2.31 and I thought that was what the builders were using so that's a mystery too. The failures occur when ld <= 2.30. Possibly this is related to which systems have gcc pass -pie by default to ld but haven't verified that. @ianlancetaylor
The text was updated successfully, but these errors were encountered: