This is the mail archive of the
mailing list for the binutils project.
Re: _bfd_elf_parse_eh_frame() should not assume relocation order?
- From: Alexey Neyman <stilor at att dot net>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 17 Dec 2013 08:19:51 -0800
- Subject: Re: _bfd_elf_parse_eh_frame() should not assume relocation order?
- Authentication-results: sourceware.org; auth=none
- References: <13342318 dot jQqOC5NQ3F at mistral> <20131217113021 dot GA28733 at bubble dot grove dot modra dot org>
On Tuesday, December 17, 2013 10:00:21 PM Alan Modra wrote:
> On Tue, Dec 17, 2013 at 01:02:03AM -0800, Alexey Neyman wrote:
> > The problem is that after 'ld -r' linking, the resulting .rela.eh_frame is
> > not
> > sorted by the r_offset:
> Why are you using ld -r? Just to package up object files? Not a good
Yes, in order to post-process the resulting object file localize the symbols
for interfaces private to a module - limiting the exposure of interfaces.
But that was not the question:
> As you have discovered, ld -r reorders things.
The question was, is it allowed to do so? Why shouldn't it sort the
relocations when writing the resulting object if it expects such ordering on
The `info ld' states the following about the -r option:
Generate relocatable output--i.e., generate an output file that can
in turn serve as input to 'ld'. This is often called "partial
I don't see how this description can be interpreted to say "`ld -r' can mess
things up to the point ld itself will produce errors when trying to link the
object file previously produced by ld".
So, is it a bug in BFD?