Massive eh_frame bloat in busybox (stripped)

[Rich Felker]

On Thu, May 10, 2012 at 05:37:43PM +0200, Joakim Tjernlund wrote:
> > From: Rich Felker <dalias at aerifal.cx>
> > To: busybox at busybox.net,
> > Date: 2012/05/10 17:26
> > Subject: Re: Massive eh_frame bloat in busybox (stripped)
> > Sent by: busybox-bounces at busybox.net
> >
> > 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).
> 
> hmm, that is annoying. Remind me, is eh_frame ONLY used for debugging or
> is there something more, like backtrace and such?

It's used for C++ exceptions, which the GCC developers believe should
be in C too... Also for backtrace, but that falls under debugging.

Rich