This is the mail archive of the binutils@sourceware.org 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: eh_frame_hdr warning


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


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