[Bug c++/53380] New: .ehframe could be smaller

[Bug c++/53380] New: .ehframe could be smaller

[msharov at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

             Bug #: 53380
           Summary: .ehframe could be smaller
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: msharov@users.sourceforge.net


The unwinding information can take up a significant (10%+) chunk of a C++
executable, and reducing its size can help make executables smaller. On x86_64
in particular, the need to include .ehframe erases code size reductions
acquired when porting 32bit code, and gives the incorrect impression that 64
bit code is larger. Fortunately, it is possible to make the unwinding table
smaller.

The entries for functions without local variables are basically empty, the
information contained being largely the offset and size of the function body.
If this type of entry was made the default action, all of them could be
removed. Then any function not found in the table would be assumed to have the
return address on top of the stack. Validity checking can still be performed by
verifying that the return address is in .text. Another optimization is to
remove entries for functions that do not throw; i.e. declared as noexcept or
not calling any other functions that are not noexcept.

Just doing these two things should remove more than half the table in a typical
executable. Of course, unwinding information is also used by the debugger and
backtrace, so the table should be left alone by default. It would be nice to
have the option to turn them on explicitly.

[Bug c++/53380] .ehframe could be smaller

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-16 23:49:09 UTC ---
Try -fno-asynchronous-unwind-tables .

Also the ABI for x86_64 requires the unwind tables IIRC.
Also i?86 enables the unwinding tables if frame pointers are disable in 4.6 and
above.

[Bug c++/53380] .ehframe could be smaller

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-05-22
     Ever Confirmed|0                           |1

[Bug c++/53380] .ehframe could be smaller

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-05-22 06:01:32 UTC ---
Did -fno-asynchronous-unwind-tables do what you wanted it to do?  In that
disable the unwinding tables when not using exceptions?

[Bug c++/53380] .ehframe could be smaller

[msharov at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

--- Comment #3 from msharov at users dot sourceforge.net 2012-05-22 11:21:41 UTC ---
> Did -fno-asynchronous-unwind-tables do what you wanted it to do?  In that
> disable the unwinding tables when not using exceptions?

No, it did not. For example:

#include <stdio.h>
int calculate (int x, int y) { return (x * y); }
void print (void) { printf ("%d", calculate(1,2)); }
int main (void) { print(); return (0); }

g++ -Os -c -fno-asynchronous-unwind-tables -o tes.o tes.cc
readelf --debug-dump=frames tes.o

Contents of the .eh_frame section:

00000000 00000014 00000000 CIE
  Version:               1
  Augmentation:          "zR"
  Code alignment factor: 1
  Data alignment factor: -8
  Return address column: 16
  Augmentation data:     1b

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset: r16 (rip) at cfa-8
  DW_CFA_nop
  DW_CFA_nop

00000018 00000010 0000001c FDE cie=00000000 pc=00000000..00000006
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

0000002c 00000010 00000030 FDE cie=00000000 pc=00000006..00000017
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

00000040 00000014 00000044 FDE cie=00000000 pc=00000000..0000000a
  DW_CFA_advance_loc: 1 to 00000001
  DW_CFA_def_cfa_offset: 16
  DW_CFA_advance_loc: 8 to 00000009
  DW_CFA_def_cfa_offset: 8
  DW_CFA_nop

As you can see, all three functions still have unwind entries emitted.
According to documentation I saw on the web, -fno-asynchronous-unwind-tables
increases unwind information granularity to function-level, meaning that it
supposedly avoids stepping cfa unless there is a function call there. While I
don't regularly read the unwind tables, I was under impression that this was
happening by default.

[Bug c++/53380] .ehframe could be smaller

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-05-22 12:55:30 UTC ---
Adding default handling if there is no FDE is an ABI change, so can't be done
on existing architectures (except those that have that in their ABI already).

Why do you care about the .eh_frame size so much?  If you don't use the unwind
info, it often won't be even paged in, or can be discarded from RAM if needed. 
And if you need it, it better be accurrate.

[Bug c++/53380] .ehframe could be smaller

[msharov at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53380

--- Comment #5 from msharov at users dot sourceforge.net 2012-05-22 18:53:32 UTC ---
(In reply to comment #4)
> Adding default handling if there is no FDE is an ABI change, so can't be done
> on existing architectures (except those that have that in their ABI already).

I was not suggesting doing it by default. A switch like
-fno-asynchronous-unwind-tables would be perfectly acceptable.

> Why do you care about the .eh_frame size so much?

I don't care "so much". I was merely suggesting a way of making it smaller, for
the use of the same people who prefer to use -Os instead -O3. Yes, I probably
could write a post-link tool to do this, but it would be much more work since I
would have to implement a disassembler, etc. to find out which functions do not
need unwind info. In the compiler you already have all that info in the parse
tree, so it is just a matter of adding a couple of if statements.

> If you don't use the unwind info, it often won't be even paged in, or can be 
> discarded from RAM if needed.

Removing unnecessary entries would make lookup faster. Making .eh_frame smaller
would also help the exception path by having less to page in.

> And if you need it, it better be accurrate.

It would still be accurate. Making the common case default does not remove any
useful information.