Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
gccgo: export data linked into binary #26204
Dumping out the .go_export section, it looks like indeed export data. I think it is not needed at run time. It probably should not be linked into the binary.
With some big binaries, like kubernetes, the export data can be quite big (over 40% of the binary size).
Executable produced by gollvm doesn't have the export data. The .o and .a files have the .go_export sections, but they don't get linked into the final executable. Gollvm invokes the linker as
gccgo linking uses collect2, as
The flags looks pretty similar. I don't know what makes the difference.
I'm not sure what is the "right" way to produce a shared library with gccgo (or gollvm). I tried
(where p.go is not main package)
This works, and libp.so contains the export data. I can then import it, like
(where main.go import package p)
With gollvm, libp.so doesn't have the export data, and I cannot do the above.
I looked into this. The reason is that when generating the object file, the .go_export section has the "e" (exclude) flag set. Gccgo doesn't set this flag. If I don't set this flag, shared libraries will have the export data, so will executables. Is there a way to instruct the linker to drop a section when we are linking executable?
In "normal" builds (i.e. using the go tool, instead of invoking gccgo or llvm-goc manually), does it need to look up the export data from shared libraries? When?
I also don't know how important it is to put export information in a shared library. Historically it worked naturally with
But I don't know if anybody actually does that. Now that gccgo includes the Go tool, it should in principle work to use