Re: _bfd_elf_parse_eh_frame() should not assume relocation order?

[Alexey Neyman <stilor at att dot net>]

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

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

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
     linking".

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?

Regards,
Alexey.