On Thu, May 10, 2012 at 05:37:43PM +0200, Joakim Tjernlund wrote: > > From: Rich Felker <[email protected]> > > To: [email protected], > > Date: 2012/05/10 17:26 > > Subject: Re: Massive eh_frame bloat in busybox (stripped) > > Sent by: [email protected] > > > > On Thu, May 10, 2012 at 04:27:33PM +0200, Joakim Tjernlund wrote: > > > [email protected] 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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
