cmd/link: DWARF data too large #5158
Labels
Milestone
Comments
one possible solution, as discussed in issue #4735, is to make the runtime use the dwarf data for backtrace so that we don't need to include two copies of data for the same information (pc <-> file:line table, for example). it will also give us more incentive to compact the dwarf sections. |
|
I believe #6853 is the main umbrella issue for tracking work in binary size reduction. That should include work in reducing DWARF data. I think this can be closed. |
|
On tip the binary is about 2M and the DWARF info is about 650K. The DWARF info is 32.5% of the executable size. So it looks like the executable size has gotten larger and the DWARF size has gotten smaller. But we're still not compressing the debug info, which would be an easy win. I'm going to leave this open at least for that. |
|
Actually, compressing debug info is #11799. Closing this one. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
At Go 1.1, roughly, this program: package main import ( "fmt" ) func main() { fmt.Println("hello") } compiled on linux/amd64 produces a 1.5MB binary, roughly half of which is debugging data (the rest is mostly runtime text and data). That data seems to be expansive and args and locals data for instance is written down twice, two different ways. It would also be possible to avoid generating much of the detail for the runtime. It would also be possible to compress the DWARF information. We should spend some time making the binaries smaller.The text was updated successfully, but these errors were encountered: