runtime.pclntab strippping

[Steeve Morin]

Hey guys,

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?

Thank you,

[Ian Lance Taylor]

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

[Steeve Morin]

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 would assume most of that happens in cmd/link/internal/ld/pcln.go right ?

Thanks!

On Friday, April 5, 2019 at 12:14:49 AM UTC+2, Ian Lance Taylor wrote:

[Ian Lance Taylor]

On Fri, Apr 5, 2019 at 5:33 AM Steeve Morin <steeve...@gmail.com> 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 golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[roj...@gmail.com]

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:

> To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[roj...@gmail.com]

i did a quick experiment with getting rid of strings - made cmd/link.ftabaddstr a no-op.

that didn't actually save that much: i got rid of all stringtab and it saved about 600K of the original 2.8M pclntab, or 20%, give or take.

the remainder compresses to about 800K with xz -9, so there's quite a bit of redundancy there.

all of the above is for ARM builds, for amd64 there's even more due to 64-bit pointers, higher bytes of which are mostly zeroes.

for this particular binary:

pclntab.amd64 - 3341578 
pclntab.amd64.nostr - 2728272

pclntab.arm5 - 2844248

pclntab.arm5.nostr - 2246896