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: [PATCH] Fix objdump output of R_SPARC_OLO10

From: Hans-Peter Nilsson <>
Date: Thu, 20 Jan 2011 02:23:16 -0500 (EST)

> On Wed, 19 Jan 2011, David Miller wrote:
>> From: Hans-Peter Nilsson <>
>> 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.

That trick works for the link hash table because the objects are
linked into, and searched/scanned within, a hash table.  This allows
the generic accessors to be agnostic about the true size of the

But the arelent's are stored in, and accessed in, a linear array,
where the size of the object is thus explicit.

I think the memory cost of an unconditional extra struct member is
cheaper, than the run-time cost of making all of the arelent array
iterators have a variable offset when walking arelents, if that's
the idea.

And even if we did implement things as you suggest, what is the
interface objdump and friends use to:

1) Figure out what auxiliary information a relocation might have

2) Determine what format that information is in and how best to
   output it

It is the BFD library client's policy how to output relocation dumps,
so this only really works if we tell them what might be there.
Which means putting the secondary addend explicitly into the
arelent and letting objdump and friends output it however they wish.

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