Re: _bfd_elf_parse_eh_frame() should not assume relocation order?

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Tue, Dec 17, 2013 at 8:19 AM, Alexey Neyman <stilor@att.net> wrote:
> 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?

I think it should be allowed.

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

Please open a binutils bug.


-- 
H.J.