This is the mail archive of the 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: _bfd_elf_parse_eh_frame() should not assume relocation order?

On Tue, Dec 17, 2013 at 8:19 AM, Alexey Neyman <> 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.


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