> 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?

 Jocke

_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to