This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove .eh_frame zero terminators

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]