cmd/link: DWARF data too large

Question

cmd/link: DWARF data too large

robpike opened this issue 13 years ago · 7 comments

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.

Answer 1 · 2013-03-30T11:21:04.000Z

Comment 1:

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.

Answer 2 · 2013-11-27T18:49:07.000Z

Comment 2:

Labels changed: added go1.3maybe.

Answer 3 · 2013-12-04T01:28:17.000Z

Comment 3:

Labels changed: added release-none, removed go1.3maybe.

Answer 4 · 2013-12-04T01:44:45.000Z

Comment 4:

Labels changed: added repo-main.

Answer 5 · 2017-12-14T16:39:42.000Z

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.

Answer 6 · 2017-12-15T02:25:27.000Z

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.

Answer 7 · 2017-12-15T02:52:08.000Z

Actually, compressing debug info is #11799. Closing this one.