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: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Alexey Neyman <stilor at att dot net>
- Cc: Alan Modra <amodra at gmail dot com>, Binutils <binutils at sourceware dot org>
- Date: Tue, 17 Dec 2013 08:48:13 -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> <18499698 dot IioVzg3OJF at mistral>
On Tue, Dec 17, 2013 at 8:19 AM, Alexey Neyman <email@example.com> 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
> 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
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
> 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.