[londons_explore]

It's time for debug info like this to be sent to "onlinesymbolserver.com", encrypted with a hash of the binary.

Then, whenever a debugger connects to a binary, it can simply download the symbols as required.

And for the 99.9% who don't need debug info, it isn't needlessly shipped.

Microsoft invented this in the 90's...

[pjmlp]

Around 1992 Borland C++ would use macro based code generation for generic code in BIDS 1.0, sounds familiar?

I guess it is just a tradition with Go, rediscovering history.

[agumonkey]

On the memory capacity of social structures.pdf

[jeffbee]

I don't think this information in Go is used for debugging alone. It's also used by mallocgc and other parts of the runtime. This is why you will see "gentraceback" in the profiles of busy Go servers. It's not because your program is printing a lot of stack traces, it's because stack walking is a core part of the GC, and because some logic in the runtime refers to the names of functions to branch around special cases.

[londons_explore]

I assume those bits of runtime could be modified to have other special markers on the functions they need to special case...

[jeffbee]

Yeah, that a function's name begins with "runtime." is 1 bit of information at most. But now we're talking about the optimal representation, not whether this information should exist.

[the_mitsuhiko]

Sadly go doesn’t care about DWARF which would allow them to reuse already existing infrastructure.

[icholy]

Go uses DWARF.

[the_mitsuhiko]

Not for unwinding or line programs.

[nappy-doo]

Go includes support for introspection. If Go used DWARF for introspection, and someone stripped DWARF, their code would break. That's not something that should happen with stripping. As such, the Go authors have made the tradeoff to have two "copies" of the data.

[icholy]

What's your point exactly?

[the_mitsuhiko]

That go is running their own stuff instead of embracing existing standards. Symbol servers and split dwarf thus is not likely to be supported.