Massive eh_frame bloat in busybox (stripped)

[Joakim Tjernlund]

> From: Timo Teras <timo.teras at iki.fi>
> To: Rich Felker <dalias at aerifal.cx>,
> Cc: busybox at busybox.net
> Date: 2012/05/10 18:24
> Subject: Re: Massive eh_frame bloat in busybox (stripped)
> Sent by: busybox-bounces at busybox.net
>
> On Thu, 10 May 2012 11:54:52 -0400 Rich Felker <dalias at aerifal.cx>
> wrote:
>
> > 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.

glibc backtrace() isn't debugging. This function should be useful even
in stripped progs.

>
> And also by pthreads when a thread is cancelled.
>
> Also note that if unwinding is needed, the absence of .eh_frame may

hmm, does C progs need unwinding?

> crash the program (especially if compiled with -fomit-framepointer).

uhh, that is no good either. Seems like non debug cases are plenty.