Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Proposal: Improve dead code ilimination when using CGO #38135

Closed
Keithcat1 opened this issue Mar 28, 2020 · 1 comment
Closed

Proposal: Improve dead code ilimination when using CGO #38135

Keithcat1 opened this issue Mar 28, 2020 · 1 comment
Labels
FrozenDueToAge Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
Proposal

Comments

@Keithcat1
Copy link

What version of Go are you using (go version)?

$ go version
go version go1.14.1 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env

What did you do?

Build an executable that uses a large C library statically linked.

What did you expect to see?

A smaller executable

What did you see instead?

A kind-of large executable.

I'm not completely sure about this, but when Go links, either statically or dynamically, I think it includes a reference to all C functions wrapped with CGO in the resulting executable, even if those functions are never called.
It would help to only include required C symbols. This could in theory help the C compiler do dead code ilimination with static libraries. Adding the CFLAGS -ffunction-sections -fdata-sections, and LDFLAGS -Wl,-gc-sections could also do something.
Thanks.
@gopherbot gopherbot added this to the Proposal milestone Mar 28, 2020
@ianlancetaylor
Copy link
Contributor

When using cgo, the Go linker builds an object file containing all the Go code, and it passes that object file to the C linker. The Go linker will discard any unused Go code. So the only references to C functions will be from Go code that might be called. Everything else is up to the C linker.

I agree with your CFLAGS and LDFLAGS suggestion, but I don't think that Go should do that by default. I think that the C compilation and linking should use just a few simple options, not options like -ffunction-sections or -Wl,--gc-sections that can cause some programs to break.

So I don't think there is anything to do here.

@ianlancetaylor ianlancetaylor added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Mar 29, 2020
@golang golang locked and limited conversation to collaborators Apr 2, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
3 participants
@ianlancetaylor @gopherbot @Keithcat1