This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH 1/6] RISC-V bfd port
On Tue, Oct 11, 2016 at 6:57 PM, Alan Modra <firstname.lastname@example.org> wrote:
> On Tue, Oct 11, 2016 at 06:17:59PM -0700, Andrew Waterman wrote:
>> On Tuesday, October 11, 2016, Alan Modra <email@example.com> wrote:
>> > On Tue, Oct 11, 2016 at 04:46:06PM -0700, Andrew Waterman wrote:
>> > > +/* Remember all PC-relative high-part relocs we've encountered to help
>> > us
>> > > + later resolve the corresponding low-part relocs. */
>> > Why? This sort of thing is usually only needed on REL targets.
>> We'll expound on this comment to explain our strategy. Of course, a simpler
>> approach might suffice.
> It's not a matter of explaining. I think you have something seriously
> wrong here. You most likely need to remove all of the hi/lo recording
> and use of high value to apply low relocs, or you have a broken ABI.
> If the latter then it would pay to fix it sooner rather than later.
> The reason hi/lo matching is needed on REL targets is that with the
> addend stored in the insn you can only fit a partial addend in an
> insn. You need to read both insns and combine the addends to create a
> full addend (which is needed to properly perform pc subtraction).
> With RELA targets you should have the full addend in the reloc.
It's not that a partial addend is being stored anywhere; it's that
there is a level of indirection. The PC-relative addressing scheme is
relative to the address of the high-part reloc, because of how the ISA
works. So, the value of the low-part reloc depends both on the
address of the high-part reloc and the symbol being referenced. The
alternative would be to put two relocs on the low-part (one for the
symbol being referenced and one for the high-part reloc). The
indirect approach seems cleaner to me.
An example might clarify:
0x1234: auipc t0, %pcrel_hi(sym)
0x1338: addi t0, t0, %prcrel_lo(0x1234)
sym = 0x45678
The %pcrel_lo needs to be filled in with ((0x45678 - 0x1234) & 0xFFF).
This approach is perhaps unconventional, but it is hard to see why it
is "seriously wrong."
> Alan Modra
> Australia Development Lab, IBM