running into the same issue: embedded system, fat Go binaries, 20% is the symbol table. +1 for slimming it down, perhaps with full non-stripped version emitted separately to analyze stack traces later (like it's common to keep non-stripped binaries for that reason). is there an issue already for that? should one be created?
On Friday, April 5, 2019 at 3:07:10 PM UTC+1, Ian Lance Taylor wrote: > > On Fri, Apr 5, 2019 at 5:33 AM Steeve Morin <steev...@gmail.com > <javascript:>> wrote: > > > > Removing the function names and file information probably constitutes > the > > most part of the size, I would guess. > > > > Do you suggest stripping it as a post processing step or modifying the > linker > > to not emit the strings in the first place? > > I'm not fond of adding a new flag to the linker, but it may not be such > a bad > > idea in a mobile context to remove function names and file information. > > I doubt it's feasible to strip the names after the fact; I think it > would have to be a linker option. (I'm not promising that such a > linker option would be accepted into the main tree.) > > > I would assume most of that happens in cmd/link/internal/ld/pcln.go > right ? > > As far as I know, yes. > > Ian > > > > On Friday, April 5, 2019 at 12:14:49 AM UTC+2, Ian Lance Taylor wrote: > >> > >> On Thu, Apr 4, 2019 at 2:32 PM Steeve Morin <steev...@gmail.com> > wrote: > >> > > >> > We are big Go users on Android and iOS thanks to golang/mobile. > >> > > >> > Lately we were doing some size profiling and stumbled upon > runtime.pclntab, > >> > which in our case represents almost 20% of the file size according to > bloaty. > >> > Now I understand that it's used for things like runtime.Caller and > panics. > >> > That said, in a mobile context panics are not that useful as this job > is handled by > >> > services like Crashlytics and DWARF. > >> > > >> > So we were wondering if it would be possible to strip it (or not emit > it altogether) > >> > and what would be the consequences/limitations of that? > >> > >> The consequences of removing pclntab would be fairly severe. You > >> wouldn't just lose runtime.Callers and stack traces and tracing and > >> profiling. The pclntab section is also used by the garbage collector > >> to traverse the stack, and by the stack copying code. I doubt that > >> many substantial Go programs would still work correctly. > >> > >> That said you could in principle drop part of pclntab with less severe > >> consequences, such as removing the function names. I don't know of > >> any supported way to do that, though. > >> > >> Ian > > > > -- > > You received this message because you are subscribed to the Google > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to golan...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6c0ca792-bfcc-41dd-bbac-1d30e1497d72%40googlegroups.com.
