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). Rich _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
