Massive eh_frame bloat in busybox (stripped)

[Rich Felker]

On Thu, May 10, 2012 at 04:27:33PM +0200, Joakim Tjernlund wrote:
> busybox-bounces at busybox.net wrote on 2012/05/10 04:44:39:
> >
> > The busybox build system first builds busybox_unstripped with debug
> > info, then uses the strip utility to obtain a non-debug busybox binary
> > that's not so bloated. However, ever since GCC switched to using
> > DWARF2 for debugging data, it puts a .eh_frame section in the output
> > binary which is NOT stripped by the strip command. See:
> >
> > $ size -A busybox
> > section       size        addr
> > .init           11   134512788
> > .text       533493   134512800
> > .fini            6   135046293
> > .rodata     146886   135046304
> > .eh_frame    72232   135193192
> > ...
> >
> > It's possible that strip -R .eh_frame could be used to remove this
> > bloat, but see my bug report here:
> >
> > http://sourceware.org/bugzilla/show_bug.cgi?id=14037
> >
> > I'm fairly confident this bug in strip can't break static binaries,
> > but I'm unsure if it's safe for dynamic-linked ones. Some checking
> > should definitely be done if it's going to be added to busybox's strip
> > command...
> 
> Looked at your bug and it seems like -R buggy, don't think
> rearranging stuff in the linker scripts will be accepted though(will
> probably create a new LOAD section)
> One quick fix(short of using /DISCARD/ could be just null the
> section(size = 0) instead of removing it completely(new option I
> guess). That should keep the ordering requirements.

Yes, if strip would need extra knowledge about the content of symbol
sections (particularly dynsym) that it presently does not have in
order to safely remove a section, then it should not fully remove it
but instead zero out its size.

By the way, note that eh_frame is generated by modern gcc even without
-g! You have to explicitly inhibit it with
-fno-asynchronous-unwind-tables (an annoyingly long option name).

Rich