Re: [PATCH] Fix objdump output of R_SPARC_OLO10

[David Miller <davem at davemloft dot net>]

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.

I guess such space could also be used by MIPS 64-bit to store the
three relocation types it has per ELF relocation entry and whatnot.

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.