This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: eh_frame_hdr warning
- From: Ian Lance Taylor <iant at google dot com>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: Alan Modra <amodra at bigpond dot net dot au>, binutils <binutils at sources dot redhat dot com>
- Date: Mon, 28 Apr 2008 22:16:48 -0700
- Subject: Re: eh_frame_hdr warning
- References: <48132F2E.2030605@codesourcery.com>
Nathan Sidwell <nathan@codesourcery.com> writes:
> I'm adding dwarf eh handing to vxworks, and I'm running into this for
> rtp shared objects. Such objects are very uclinux-like, in that the
> delta between text and data segments is not fixed at link time. So we
> can't generate a relative .eh_frame and therefore can't generate a
> .eh_frame_hdr.
In order for gcc to use the sorted table which is part of the
.eh_frame_hdr, you need to be able to produce a 32-bit offset from the
start of the table to the FDE entry in the .eh_frame section. That is
normally possible--it is similar to a relative branch. However, if it
can not be done, then you should generate the .eh_frame_hdr without
the lookup table--the DW_EH_PE_omit case in
_bfd_elf_write_section_eh_frame_hdr.
However: .eh_frame_hdr is only useful if the gcc support libraries can
find it at run time. With ELF this is done by looking for the
PT_GNU_EH_FRAME program segment, using dl_iterate_phdr. Does that
work with vxworks? If not, then gcc should be configured to not pass
--eh-frame-hdr to the linker--this is HAVE_LD_EH_FRAME_HDR in gcc.
Ian