[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. Teaching strip using stdin and stdout would be great too Jocke _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
