This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] Fix objdump output of R_SPARC_OLO10
On Wed, 19 Jan 2011, David Miller wrote:
> From: Hans-Peter Nilsson <hp@bitrange.com>
> Date: Wed, 19 Jan 2011 18:20:54 -0500 (EST)
>
> > On Wed, 19 Jan 2011, David Miller wrote:
> >
> >> Because that's what such a callback would need to do since there is no
> >> reasonable place to store the second addend for the relocations.
> >>
> >> That's the whole gist of the problem, "arelent" is insufficent for
> >> storing the necessary data to represent this relocation fully.
> >
> > Is extending it out of question?
>
> Why should every BFD target pay the storage price for a feature
> which only one target actually uses?
>
> I'm more than happy to do it, but I anticipated resistence to
> such a change.
There wouldn't be any if you did it by extending the structure
at the end, and had target-specific (and ELF-specific)
overridable initialization and setting functions, like is done
for most (all?) DSO-capable targets with elf_link_hash_table.
> Another idea I had was, instead of caching the howto pointer, just
> storing the full r_info value from the relocation. I could justify
> this if the average number of howto entry lookups remains about
> the same, but my initial impression is that it would approximately
> double them.
That would work too I guess, but this is getting closer to
rewriting the BFD ELF-handling. :-)
brgds, H-P