3 ms·
So what is the solution then? Will they just have to fork Go and compress the table again like before? It's completely insane that it would eventually surpass t
by warent 7y ago
So what is the solution then? Will they just have to fork Go and compress the table again like before? It's completely insane that it would eventually surpass the size of the program itself.
- kseistrup 7y agoIs the line table in go executables absolutely essential? Shouldn't they be strippable, the way you can strip debug symbols from a C binary?
- Carpetsmoker 7y agoThey are, and many people don't include them in production builds. This article is incomplete for not mentioning it.
- nneonneo 7y agoI did a quick search and turned up nothing about stripping the pclntab (note: distinct from the DWARF line-number tables which can be stripped). A post on Google Groups suggests the opposite - pclntab cannot be stripped because the runtime needs the info for GC - https://groups.google.com/forum/m/#!topic/golang-nuts/hEdGYnqokZc https://groups.google.com/forum/m/#!topic/golang-nuts/hEdGYn....
- caiobegotti 7y agoYou're right, but that wouldn't make the main problem go away though. I just built a simple plugin for Kubernetes's kubectl and it's about 32MB with go build's -ldflags -s -w where 16MB of that is still the pclntab mentioned in the article.
- Carpetsmoker 7y agoThe problem with removing that completely is that you won't get any information on panics. I don't think this is what you really want, and the current behaviour strikes me as a reasonable middle ground. 32M is really large for a simple plugin, and to be honest I think that says just as much about Kubernetes as it says about Go.
- knz42 7y agoNo you cannot strip away pclntab, it is necessary to implement the (mandatory, often used) runtime.Callers API.