This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Question regarding processing of .eh_frame sections during partial linking on elf64-ppc platforms
- From: Alan Modra <amodra at bigpond dot net dot au>
- To: "William H. Maddox III" <maddox at transmeta dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 7 Dec 2006 01:30:52 +1030
- Subject: Re: Question regarding processing of .eh_frame sections during partial linking on elf64-ppc platforms
- References: <456EBB09.60903@transmeta.com> <20061130225152.GA4384@bubble.grove.modra.org> <45767DCF.4060104@transmeta.com>
On Wed, Dec 06, 2006 at 12:22:39AM -0800, William H. Maddox III wrote:
> Alan Modra wrote:
> > On Thu, Nov 30, 2006 at 03:05:45AM -0800, William H. Maddox III wrote:
> >> I am seeing relocations
> >> for an FDE start PC that point to the single instance of a linkonce
> >> section that is preserved, but which have ranges that indicate
> >> that the FDEs arose from function instances in discarded sections.
> >
> > You've hit a ld bug. ld is supposed to process .eh_frame and remove
> > FDEs for discarded linkonce sections. It does this for both final
> > and relocatable linking. Testcase?
>
[snip]
> What I found, though, is that
> _bfd_elf_discard_section_eh_frame is not called for a "-r" link,
> apparently by design.
Sigh. You're right, "ld -r" doesn't process .eh_frame. This is
probably why you're seeing bogus FDEs. I think that after "ld -r" has
mashed together files we lose the capability to easily determine which
FDEs belonged to discarded sections. So that should be fixed.
I'll look into it more tomorrow.
--
Alan Modra
IBM OzLabs - Linux Technology Centre