> The sum of the sizes reported by go tool nm does not add up to the final size of the Go executable.<p>> At this time, I do not have a satisfying explanation for this “dark” file usage.<p>The author's journey of starting with "nm --size", discovering "dark" bytes, and wanting to attribute them properly, is <i>exactly</i> what led me to create and invest so much effort into Bloaty McBloatface: <a href="https://github.com/google/bloaty" rel="nofollow">https://github.com/google/bloaty</a><p>Bloaty's core principle is that every byte of the file should be attributed to something, so that the sum of the parts always adds up to the total file size. If we can't get detailed symbol, etc. information for a given region of the file, we can at least fall back to describing what section the bytes were in.<p>Attributing all of the bytes requires parsing much more than just the symbol table. Bloaty parses many different sections of the binary, including unwind information, relocation information, debug info, and the data section itself in an attempt to attribute every part of the binary to the function/data that emitted it. It will even disassemble the binary looking for references to anonymous data (some data won't make it into the symbol table, especially things like string literals).<p>I wrote up some details of how Bloaty works here: <a href="https://github.com/google/bloaty/blob/master/doc/how-bloaty-works.md" rel="nofollow">https://github.com/google/bloaty/blob/master/doc/how-bloaty-...</a>. The section on the "Symbols" data source is particularly relevant here:<p>> I excerpted two symbols from the report. Between these two symbols, Bloaty has found seven distinct kinds of data that contributed to these two symbols. If you wrote a tool that naively just parsed the symbol table, you would only find the first of these seven:"<p>The author's contention that these "dark" bytes are "non-useful" is not quite fair. There are plenty of things a binary contains that are useful even though they are not literally executable code. For example, making a binary position-independent (which is good for security) requires emitting relocations into the binary so that globals with pointer values can be relocated at program load time, once the base address of the binary is chosen. I don't know if Go does this or not, but it's just one example.<p>On the other hand, I do agree that the ability to produce slim binaries is an important and often undervalued property of modern compiler toolchains. All else being equal, I much prefer a toolchain that can make the smallest binaries.<p>Bloaty should work reasonably well for Go binaries, though I have gotten some bug reports about things Bloaty is not yet handling properly for Go: <a href="https://github.com/google/bloaty/issues/204" rel="nofollow">https://github.com/google/bloaty/issues/204</a> Bloaty is just a side thing for me, so I often don't get as much time as I'd like to fix bugs like this.