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: sectionForAddress(0xA9D67F) address not in any section file [1.15 backport] #40974
Comments
I can repeat
It fails too, and I can reproduce exact same linker error by running the same command:
|
Thanks for the report. Is there any way we can reproduce it ourselves? With the current information it is hard to tell what's wrong. If you add |
@cherrymui Thanks. I attempted to minimize the failing case, but in the time I had, I failed to find anything. But your idea sheds some light, as it works without debugging symbols:
|
Thanks for the information. Could you get the intermediate
and look at /tmp/xxx/go.o (replace /tmp/xxx with a temp directory you like). Maybe run |
@cherrymui Thanks. Output:
|
I've seen a nearly identical issue in several of my projects (the error message reports a different address, but otherwise looks to be the same): $ go build ./cmd/service
# path/to/my/repo/cmd/service
/usr/local/opt/go/libexec/pkg/tool/darwin_amd64/link: running clang failed: exit status 1
ld: sectionForAddress(0xA2F51E) address not in any section file '/var/folders/yt/7ql8k1yn67s0qfhcvytsn7g00000gn/T/go-link-948504621/go.o' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation) I am also building for macOS natively. The error goes away if I do any of the following:
The fact that upgrading all my dependencies seems to fix it is very interesting to me. I haven't had a chance to bisect down to what individual upgrade (if any) fixes the issue. |
Thanks for the information. From what you posted it seems we generated a DWARF relocation targeting |
I'm seeing this same error when running Minimally redacted output
My environment
I would share more but this is an internal project. |
Hmmm, there are a few places in DWARF where we reference the end address of text section. But they are the same in Go 1.14 as well. Not sure what changed... |
I noticed @wkoszek mentioned running into this with a file named I'm not sure if that's just a red herring and just coincidence (we already had/have at least 2 other files named |
@joesteele I don't think that's it. I'm getting it now on a project without a "asset.go", and the bug still exists. |
Yeah, I figured it was just a coincidence, but when I saw that I was like 🤨 , haha. |
The same thing happened to me. Go version Successful sample
Failure sample
|
@fsyyft Is example/cmd/... something you could share with us here? The issue is that developers can't reproduce this issue in an easy way. |
Thank you very much for your attention. In
The result of my latest attempt is as follows. After modifying the following code, I finally compiled it. I don't know whether this information is useful or not. This change of position is in Old
New
Some additional informationUnlike my friend's test example, which I also tried before modifying the init method's code, I couldn't find the corresponding string in either of the files,
|
It would be great if someone could share a way for us to reproduce it ourselves. If not, could someone share the intermediate go.o object files for both Go 1.14 (successful build) and Go 1.15 (failed build)? (#40974 (comment) has the instruction to get the go.o file.) I see where we might generate such relocations but I don't see what changed from Go 1.14 to 1.15. Thanks. |
https://github.com/fsyyft/golang15/tree/develop/build I have passed the relevant intermediate data, please check whether it is useful. |
@fsyyft thanks for sharing the files. I think I understand it now. The problem is the DWARF line table, where we emit end_sequence op at a PC that may overrun the text section, if it is the last function in the section. This seems to be CL https://go-review.googlesource.com/c/go/+/235739 . cc @thanm For example, (@fsyyft 's go.o)
We advance the PC by 9 at the last step, but text section ends at 0x74483e, and the rodata section starts 0x744840. The darwin linker doesn't like this. This doesn't always fail because of alignment padding. If it advances the PC by 9 but still not reaches the next section, it is okay (the darwin linker has some tolerance). The relevant code has been rewritten (CL https://go-review.googlesource.com/c/go/+/239286 ), and it should not have this problem on tip. @fsyyft @wkoszek and anyone run into this problem, could you try building Go 1.15 linker with these two lines commented out https://go.googlesource.com/go/+/refs/tags/go1.15.2/src/cmd/link/internal/ld/dwarf.go#1275 ? Or try Go tip? They should work if my understanding is correct. |
I'm not sure what is the best solution for Go 1.15. The version at tip is better, but I'm not sure it is possible to backport. @thanm is it possible? Is it too much for a backport? If not, maybe the only way is to not advance the PC on darwin, as in the linker we don't know what the current PC is so we cannot advance just enough to not overrun the section. Or maybe only not do it for the very last function. This is unfortunate, but probably fine... |
@cherrymui good detective work figuring this out... I think it might be possible to back-port. I'll take a shot at it and see if I can do it in a clean way. Stay tuned. |
I think it should back-port cleanly. I'll prepare the CL for review. I assume that this should be against the 1.15 release branch, since this is not a situation where we'll have a fix on tip that gets cherry-picked back. |
Change https://golang.org/cl/258422 mentions this issue: |
Approved as this is a serious issue without a valid workaround. |
Closed by merging 8f14c18 to release-branch.go1.15. |
During Go 1.15 development, a fix was added to the toolchain for issue information. The 1.15 line tables were slightly malformed in the way that they used the DWARF "end sequence" operator, resulting in incorrect line table info for the final instruction in the final function of a compilation unit. This problem was fixed in https://golang.org/cl/235739, which made it into Go 1.15. It now appears that while the fix works OK for linux, in certain cases it causes issues with the Darwin linker (the "address not in any section" ld64 error reported in issue #40974). During Go 1.16 development, the fix in https://golang.org/cl/235739 was revised so as to fix another related problem (described in issue #39757); the newer fix does not trigger the problem in the Darwin linker however. This CL back-ports the changes in https://golang.org/cl/239286 to the 1.15 release branch, so as to fix the Darwin linker error. Updates #38192. Updates #39757. Fixes #40974. Change-Id: I9350fec4503cd3a76b97aaea0d8aed1511662e29 Reviewed-on: https://go-review.googlesource.com/c/go/+/258422 Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Jeremy Faller <jeremy@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Trust: Than McIntosh <thanm@google.com>
Hello everyone, I am also faced with this issue using 1.15.3. |
@ivanovaleksey yes, it should be in Go 1.15.4. Thanks. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I decided to upgrade today:
I upgraded only Golang, nothing else.
This resulted in my project crashing at building of test executable:
I parametrized my
makefile
and fetched 2 versions of Golang from the website:go1.14.7.darwin-amd64.tar.gz
go1.15.darwin-amd64.tar.gz
Reproducing of 1.15 issue:
Proof 1.14.7 is OK:
What did you expect to see?
I'd expect 1.15 to behave like 1.14.7
What did you see instead?
More findings
The structure of the project is
dataops/{cli, dephi, debug}
. Incli/
dir I have work-in-progress fileasset.go
which depends on our privatedephi
module published on GitLab.dephi
module just carries1.8MB
of string constants which are meant to be compiled into the package. Indataops/dephi
, I usepkger
to get:Other than that, "dephi" is very trivial -- 1 .go file -- which returns constants as
[]string
. Now the funny part:cli/asset.go
is very-work-in-progress: it hasAssetsList()
which isn't called from anywhere. But by movingasset.go
out of the project, I made it compile fine with go1.15.To isolate whether
asset.go
is a culprit I madedebug/
directory, with some mocks, but I also depend onasset.go
and I usedephi
. It works OK:I attempt to emulate impact of unused code by making unused_to_test.go with 1 global function not called from anywhere. No luck in reproducing -- this project builds fine with Golang 1.15.
Summary:
asset.go
itself and probablypkger
aren't the main culprit. It appears like a combination of other factors exposes this linker issue.The text was updated successfully, but these errors were encountered: