-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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: TestDWARF failing under all.bash on OSX 10.13.6 #30236
Comments
$ clang --version |
I am unable to reproduce this on my mac -- which is at 10.13.6 but a slightly different clang version:
The error you're seeing is one that happens very early in the .debug_info read, seeming to indicate that the DWARF is truncated or missing. FWIW I can't find your clang version in https://gist.github.com/yamaya/2924292 is there anything unusual about it? |
I didn't do anything unusual. That is the version I get when I uninstall (rm -rf /Library/CommandLineTools) and type I also uninstalled and downloaded the most recent version from: Command Line Tools (macOS 10.13) for Xcode 10.1 Nov 2, 2018 This installer installs the exact same version. googling for "Apple LLVM version 10.0.0 (clang-1000.10.44.4)" leads me to this: |
Interestingly, I uninstalled CommandLineTools and installed Xcode from the App store. and got a different clang version: Apple LLVM version 10.0.0 (clang-1000.11.45.5) I still get the same test error though. |
@timothyham are you willing to try a few examples to gather more info?
In the output from the go build line there should be a "host link:" execution -- what does that look like? Also, what do you get when you run "objdump -section-headers" on the resulting executable (himom)? I'm grasping at straws here; without a way to reproduce the problem on my own machine it's hard to know what to suggest. |
@thanm Thanks for your help. I am happy to run whatever to diagnose this problem. Here is my output:
my himom.go:
|
Clang invocation looks fine, but in spite of the "-g" flags, the resulting executable has no DWARF (which is obviously not what we're expecting). One more experiment if you can manage, please. After running the "go build" command, just replay the clang host link invocation, but tack on a "-v", e.g. "clang" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" "-Wl,-pagezero_size,4 Then look at the section headers again with objdump. [This will hopefully tell us whether the problem is with clang or with dsymutil] |
Here is my interactive session. I tried to follow what you were saying about "-v":
|
Thanks, but I think you need to run objdump on /var/folders/jw/jl09r8zn7yxcg04glntytrl07k6c17/T/go-build400191060/b001/exe/a.out (that's the output of the clang invocation you ran). |
here you go:
|
@timothyham thanks for that. I am stumped at this point -- I will ask around and see what I can discover. Stay tuned. |
Thanks for looking. Since you cannot reproduce the problem, it must be something different about my machine. Can't imagine what though. |
@timothyham Is this issue still causing problems for you -- can it be closed out? |
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?
Try to build go from source.
What did you expect to see?
successful build
What did you see instead?
--- FAIL: TestDWARF (3.88s)
--- FAIL: TestDWARF/testprogcgo (1.95s)
dwarf_test.go:98: decoding dwarf section info at offset 0x0: too short
FAIL
FAIL cmd/link 5.179s
--- FAIL: TestRuntimeTypeAttrExternal (1.02s)
dwarf_test.go:945: error reading DWARF: decoding dwarf section info at offset 0x0: too short
FAIL
FAIL cmd/link/internal/ld 2.336s
The text was updated successfully, but these errors were encountered: