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: nil pointer dereference #34249
Comments
When I do a build of your code using the "go" command (as opposed to raw 'go tool compile' and 'go tool link' invocations), it seems to work fine: $ go build -o tiny -buildmode=plugin tiny.go $ When I run the same build using "-x" I can see that the Go command is using a number of other important compiler and linker flags needed for the plugin to work (for example, the '-dynlink' compiler option, which would seem to be mandatory given how plugins are supposed to be used). Is there a reason why you're not using these options in your 'go tool compile/link' invocations? Thanks. |
I was not aware of the |
I think it is safe to say that that users are expected to build their code "go build" as opposed to raw "go tool compile" and "go tool link" invocations (unlike, say, a C compiler, where you can do just fine with a strategy like "cc -c myfile.c ; cc -o myprog myfile.o"). There may have been a time many releases ago when you could get by on just "go tool compile" and "go tool link", but those days are gone at this point -- the Go command does a lot of careful orchestration of the compiler and linker options depending on what and how you are building. You can see this in action by looking at the output of "go build -x -buildmode=... ...". |
I imagine that a compiler crash is not the intended behaviour when incorrect linker flags are passed though, yes? Additionally, if such is the case, why are these utilities exposed as |
Many programming tools expose features to make life easier for the developers of those tools. Consider GDB's "maintenance info program-spaces" command, or GCC's "-fdump-tree-all-all" command line options -- yes, they are exposed, but it's not expected that they be used by anyone other than developers of GCC or GDB. The go tool commands fall into the same category. Regarding the crash on a weird combination of options -- this is surely a bug of some sort... would you like to send a patch? |
Thank you for the elaboration, I understand what you meant now. I suggested a patch that simply checks for |
What version of Go are you using (
go version
)?(the latest
master
)Does this issue reproduce with the latest release?
Exists on 1.13,
master
and 1.12.9What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Created a file called
main.go
, with the following contents:Then ran the following commands:
What did you expect to see?
As is the case with
go tool link main.o
, no output is produced and a.so
file will be created.What did you see instead?
At https://github.com/golang/go/blob/master/src/cmd/link/internal/sym/symbol.go#L289,
s
or,self
, isnil
and at https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/dwarf.go#L1556 thenil
symbol is loaded from the dwarf information. Strangely enough, disabling dwarf with-dwarf=false
does not prevent this crash.Furthermore, when inserting the following code at the location above in
dwarf.go
to skipnil
sections:It will then trigger the following error when linking:
The text was updated successfully, but these errors were encountered: