Re: Remove .eh_frame zero terminators

[Alan Modra <amodra at gmail dot com>]

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.

-- 
Alan Modra
Australia Development Lab, IBM