.eh_frame bloat issue and solution
 

I saw this a couple of days ago on the busybox mailing list. See...
http://comments.gmane.org/gmane.linux.busybox/36695

> By default, modern GCC generates DWARF2 debug/unwind tables in the
> .eh_frame section of the object files/binaries. This adds significant
> bloat (as much as 15%) to the size of the busybox binary, including
> the portion mapped/loaded into memory at runtime (possibly a big
> issue for NOMMU targets), and the section is not strippable with
> the strip command due to being part of the loaded program text.

[...deletia...]

> it seems the solution is to add to the CFLAGS -fno-unwind-tables
> and -fno-asynchronous-unwind-tables.

I realize that busybox is used in embedded environments, and physical
size and memory footprint is critical there. How do Gentoo devs feel
about it? Would there be any problems with users adding
-fno-unwind-tables and -fno-asynchronous-unwind-tables to CFLAGS and
CXXFLAGS? Should it be mentioned in the install manual as an option for
users to possibly include?

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

.eh_frame bloat issue and solution
 

On Wed, Sep 05, 2012 at 10:11:05PM -0400, Walter Dnes wrote:
> I saw this a couple of days ago on the busybox mailing list. See...
> http://comments.gmane.org/gmane.linux.busybox/36695
Probably a question best for vapier & our toolchain folks, but any
reason we can't modify splitdebug to put the .eh_frame into the debug
file only and explicitly strip from the main binaries?

--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85