Re: Remove .eh_frame zero terminators

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Aug 31, 2017 at 5:40 AM, Alan Modra <amodra@gmail.com> wrote:
> On Thu, Aug 31, 2017 at 04:26:40AM -0700, H.J. Lu wrote:
>> On Thu, Aug 31, 2017 at 3:35 AM, Alan Modra <amodra@gmail.com> wrote:
>> > The machinery to do this was there, but not enabled if the terminator
>> > was the only thing in the section.
>> >
>> > We should have seen quite a lot of exception handling failures due to
>> > ld's nasty LTO support.  It has the habit of adding object files
>> > extracted from archives after crtend.o, the file that has the
>> > .eh_frame terminator.  The saving grace is that with --eh-frame-hdr
>> > there doesn't need to be a scan of section contents (which would
>> > terminate on hitting the terminator) for an FDE covering a given
>> > address.
>>
>> What will happen with -static -flto?  --eh-frame-hdr isn't used with -static.
>
> Well, if you take a look at a map file from lto-2.exe in the ld
> testsuite, you'll see something like
>
> .eh_frame       0x00000000004d36d0     0xb848
>  *(.eh_frame)
>  .eh_frame      0x00000000004d36d0       0x30 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
>  .eh_frame      0x00000000004d3700        0x0 /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbeginT.o
>  .eh_frame      0x00000000004d3700       0x30 /tmp/ccTnDsOu.ltrans0.ltrans.o
>  .eh_frame      0x00000000004d3730       0x80 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libc.a(libc-start.o)
>                                          0x98 (size before relaxing)
> [snip lots more libc]
>
>  .eh_frame      0x00000000004dd498      0x518 /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2.o)
>                                         0x530 (size before relaxing)
>  .eh_frame      0x00000000004dd9b0      0x570 /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-dw2-fde-dip.o)
>                                         0x588 (size before relaxing)
>  .eh_frame      0x00000000004ddf20       0xa0 /usr/lib/gcc/x86_64-linux-gnu/4.9/libgcc_eh.a(unwind-c.o)
>                                          0xb8 (size before relaxing)
>  .eh_frame      0x00000000004ddfc0       0x40 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libc.a(dl-iteratephdr.o)
>                                          0x58 (size before relaxing)
>  .eh_frame      0x00000000004de000        0x0 /usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
>                                           0x4 (size before relaxing)
>  *fill*         0x00000000004de000        0x0
>  .eh_frame      0x00000000004de000      0x1e0 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libm.a(s_sin.o)
>                                         0x1f8 (size before relaxing)
> [snip more libm]
>  .eh_frame      0x00000000004dec08      0x2b8 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libm.a(mpa-fma4.o)
>                                         0x2d0 (size before relaxing)
>  .eh_frame      0x00000000004deec0       0x58 /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/libc.a(printf_chk.o)
>                                          0x78 (size before relaxing)
>
> crtend.o is where the zero terminator lives, so if that wasn't deleted
> as it is now, I think any following .eh_frame info will not be
> registered.  If this was a C++ example with try/catch and you managed
> to generate an exception in any object linked after crtend.o, it won't
> be caught and instead the program will terminate.
>

We should revisit:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54568

At least always pass --eh-frame-hdr to ld for -flto.

-- 
H.J.