> From: Timo Teras <[email protected]> > To: Rich Felker <[email protected]>, > Cc: [email protected] > Date: 2012/05/10 18:24 > Subject: Re: Massive eh_frame bloat in busybox (stripped) > Sent by: [email protected] > > On Thu, 10 May 2012 11:54:52 -0400 Rich Felker <[email protected]> > wrote: > > > 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.
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. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
